Edit report at http://bugs.php.net/bug.php?id=50921&edit=1
ID: 50921
Comment by: tyra3l at gmail dot com
Reported by: phpbug at starurl dot com
Summary: '200 OK' HTTP status despite PHP error
Status: Bogus
Type: Bug
Package: HTTP related
Operating System: *
PHP Version: 5.2.12
Block user comment: N
New Comment:
I can reproduce the problem.
I found out, that if I enable xdebug, then I get header 200, if I
disable it, then
it's 500.
Will report it to Derick.
Tyrael
Previous Comments:
------------------------------------------------------------------------
[2010-03-12 08:37:24] anzenews at volja dot net
I am also having huge problems with this - haproxy health checks do not
work reliably because of this bug. Please consider reopening it - it is
not bogus.
PHP doesn't return HTTP error code, even if display_errors is set to 0.
One example:
<?
ini_set('display_errors',0);
this_function_does_not_exist();
echo "ok";
?>
This returns an empty page with status code 200:
-----
HTTP/1.1 200 OK
Date Fri, 12 Mar 2010 07:27:15 GMT
Server Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny6 with Suhosin-Patch
X-Powered-By PHP/5.2.6-1+lenny6
Vary Accept-Encoding
Content-Encoding gzip
Content-Length 20
Keep-Alive timeout=15, max=100
Connection Keep-Alive
Content-Type text/html
-----
Content-Length is 20, probably because of gzip? There are no spaces
around PHP block in source code.
I have checked phpinfo() and display_errors is set to Off, so there is
no error there. Also, I have tried setting it in php.ini - no change.
Another problem: parse errors are also not handled correctly (even if
display_errors is set to 0 in php.ini). See previous poster's example.
Thanks!
------------------------------------------------------------------------
[2010-02-03 19:03:56] der...@php.net
The reason why display errors needs to be turned of, is because
displayed errors generate output, and output causes the headers to be
send out. I'm afraid we can't do much about this.
------------------------------------------------------------------------
[2010-02-03 18:01:37] phpbug at starurl dot com
Thank you for the swift response Jani.
I can confirm that the 500 status code works for the following (runtime
error):
<?
ini_set('display_errors', 0);
$x = y();
?>
But fails for parse errors (because the "disply_errors" line doesn't get
executed):
<?
ini_set('display_errors', 0);
x = y;
?>
Firstly, is this dependency really necessary? Just because we have
'display_errors' enabled doesn't mean we want fatal errors to go
unlogged and unnoticed because a "200 OK" status is incorrectly
returned.
Secondly, the majority of PHP developers out there use shared hosting,
on which 'display_errors' is normally true and is impossible to change
globally - are we saying they're stuck with incorrect HTTP status codes
when parse errors occur?
The restriction that headers must not already have been sent is of
course understandable as it is unavoidable. Not overriding an explicitly
set HTTP status code also makes sense.
But why not set the status code as "500 Internal Server Error" when any
fatal parse/runtime error occurs, regardless of the value of
'display_errors'? This would be consistent with the HTTP spec, which
recommends a 5XX response if an error occurs, and is followed by just
about every other web server language out there (e.g., ASP, .NET).
Many thanks, BJ
------------------------------------------------------------------------
[2010-02-03 10:06:27] j...@php.net
It does happen. It requires that:
1) display_errors = off
2) No headers have been sent yet by the time the error happens
3) Status is 200 at that time.
------------------------------------------------------------------------
[2010-02-03 04:23:42] phpbug at starurl dot com
Description:
------------
My host runs PHP v5.2.12 (confirmed via phpversion) on IIS6 (Windows
Server, unknown version). When a PHP error occurs (parse error, runtime
error, etc), a "200 OK" HTTP status is returned, instead of the correct
"500 Internal Server Error".
This is despite claims in the change history for v5.2.4 that this issue
was fixed: "Changed error handler to send HTTP 500 instead of blank
page on PHP errors. (Dmitry, Andrei Nigmatulin)". This doesn't appear to
be the case on IIS6 (monitored remotely via HTTP Spy).
Reproduce code:
---------------
<?
x = y; // cause parse error
?>
Expected result:
----------------
Parse error mesage and "500 Internal Server Error" HTTP status code.
Actual result:
--------------
Parse error mesage and "200 OK" HTTP status code
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=50921&edit=1
