php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #45592 eval'ed Code throws HTTP 500 error when display_errors is off
Submitted: 2008-07-22 15:13 UTC Modified: 2008-07-23 09:52 UTC
From: andy at boeckler dot org Assigned:
Status: Not a bug Package: Output Control
PHP Version: 5.2.6 OS: Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: andy at boeckler dot org
New email:
PHP Version: OS:

 

 [2008-07-22 15:13 UTC] andy at boeckler dot org
Description:
------------
I'm getting Ajax-Request-Failures since PHP5 throws HTTP-500 Errors back.
This was not the case before upgrading from PHP4.

This is annoying:
* E_STRICT are filtered out
* when display_errors is ON, the request is OK!
* display_errors ON is no option on a productionserver

It only works, when ob_flush() is called before exit() (see staticFunc2)

Reproduce code:
---------------
<?php
error_reporting(E_ALL & ~E_NOTICE); // NO E_STRICT is in here
ini_set('display_errors', 'off');
//ini_set('display_errors', 'on');

class Test {
 public staticFunc() { echo 'boo'; exit(); }
 public staticFunc2() { echo 'boo'; ob_flush(); exit(); }
}

Test::staticFunc();

?>

Expected result:
----------------
HTTP 200

Actual result:
--------------
HTTP 500, w/o ob_flush() when display_errors is off
HTTP 200, w/o ob_flush() when display_errors is ON
HTTP 200, with ob_flush()

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-07-22 15:25 UTC] andy at boeckler dot org
Update:
ob_flush() doesn't change anything ...
I accidentally tested it with display_errors=ON
 [2008-07-22 22:15 UTC] jani@php.net
You have a parse error there:

PHP Parse error:  syntax error, unexpected T_STRING, expecting T_VARIABLE in /home/jani/t.php on line 7

And I don't get any E_STRICT notices with fixed version of this code either..
 [2008-07-22 22:53 UTC] andy at boeckler dot org
Sorry .. 
the code example goes in the wrong direction 
I've narrowed the actual issue. It has to do with evaled code.
The @eval-Function is not catched properly.

<?php
error_reporting(E_ALL & ~E_NOTICE);

class Test {
    function func1() { // HTTP 500                                                                                                                                   
        ini_set('display_errors', 'off');
        @eval('completely wrong');
        echo 'boo'; exit();
    }
    function func2() { //HTTP 200                                                                                                                                    
        ini_set('display_errors', 'on');
        @eval('completely wrong');
        echo 'boo'; exit();
    }
    function func3() { // HTTP 200  and HTTP 500 with output buffering                                                                                               
        ini_set('display_errors', 'off');
        echo 'noerror';
        @eval('completely wrong');
        echo 'boo'; exit();
    }
}

Test::func1();
//Test::func2();                                                                                                                                                     
//Test::func3();                                                                                                                                                     
?>
 [2008-07-22 23:12 UTC] jani@php.net
That's expected behavior. 

In PHP 5.2.4 NEWS:

"Changed error handler to send HTTP 500 instead of blank page on PHP errors. "

And in the manual page for eval(): http://docs.php.net/eval

"If there is a parse error in the evaluated code, eval() returns FALSE and execution of the following code continues normally. It is not possible to catch a parse error in eval()  using set_error_handler()."

 [2008-07-22 23:23 UTC] andy at boeckler dot org
"Changed error handler to send HTTP 500 instead of blank page on PHP
errors. "

1. I've never seen a blank page in PHP4, when i'm doing @eval !
2. Why does it work with display_errors on?
3. Why does it work, when i'm doing an "echo" BEFORE the @eval?
 [2008-07-23 09:52 UTC] andy at boeckler dot org
Why bogus?

This is by no means a consequent error-reporting.
 [2010-08-03 10:48 UTC] quamis at gmail dot com
I've ran into the same problem on 5.2.9. Because of an error in the eval'd code(and the subsequent 500-Internal error generated), the headers i was sending from my app would get misinterpreted by the browser and would display a "File Not Found"...
I tracked this to a combination of "display_errors off" and the eval function.
 [2011-11-25 07:33 UTC] ananda dot pryana at gmail dot com
Just a note that this bug still exists in PHP version 5.2.17.

I don't think this is bogus. Based on the quoted manual, the bug is that "execution of the following code continues normally" part does not happen when display_error is OFF, but happens when display_error is ON.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 15:01:29 2024 UTC