|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #50921 '200 OK' HTTP status despite PHP error
Submitted: 2010-02-03 04:23 UTC Modified: 2010-03-12 16:04 UTC
From: phpbug at starurl dot com Assigned:
Status: Not a bug Package: HTTP related
PHP Version: 5.2.12 OS: *
Private report: No CVE-ID:
 [2010-02-03 04:23 UTC] phpbug at starurl dot com
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


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-02-03 10:06 UTC]
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 18:01 UTC] 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 19:03 UTC]
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-03-12 08:37 UTC] 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:
  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. 

 [2010-03-12 16:04 UTC]
-Operating System: Windows IIS6 +Operating System: *
 [2010-08-12 15:35 UTC] tyra3l at gmail dot com
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.

 [2010-08-12 15:40 UTC] tyra3l at gmail dot com
It's seems that this is a known bug in the xdebug, see:

but couldn't fix it without making some changes in php itself:

"Before I can address this, there need to be some changes in PHP itself. It 
doesn't expose some required information to extensions yet that I will need."

I hope this get fixed soon.

 [2010-11-19 11:48 UTC] dean at deansas dot org
> 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.

Can't PHPs error handling first set a 500 header and then output
error messages as appropriate? 

It doesn't seem to me like this is something that can never ever be fixed
 [2013-04-13 19:01 UTC] matteosistisette at gmail dot com
The status is wrong. And oh my god, since 2010!!

This IS a bug.

Display_errors off means don't DISPLAY errors, it shouldn't have any effect on 
the response code.

Default response for fatal errors should be 500 whether or not display_errors is 
turned on.
 [2013-05-28 21:42 UTC] kwintersnc at gmail dot com
According to this is fixed in PHP 5.4, so 
"Not a bug" isn't correct.
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Fri Apr 18 08:02:55 2014 UTC