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.

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

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.

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!

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

It's seems that this is a known bug in the xdebug, see:
http://bugs.xdebug.org/view.php?id=587

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.

Tyrael

> 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

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.

According to http://bugs.xdebug.org/view.php?id=587 this is fixed in PHP 5.4, so 
"Not a bug" isn't correct.

still having this issue with "PHP Version: 5.4.27-1+deb.sury.org~precise+1" with xdebug turned on or off, doesn't seem to make a difference ...

display_errors off does, as already stated by others.

I can also confirm the issue still exists: PHP Version 5.4.16

This is an error for us as well, running on 5.4.28 on Google App Engine, with and without XDebug. This definitely needs to be fixed.

the xdebug issue was a separate problem, and is indeed fixed.
what is still not "fixed" is that if you enable display_errors, then the error message itself will trigger sending out the response which sets the http 200 implicitly.
if we go ahead and change this, we should make sure to only add the http 500 when the script execution is actually terminated by the error(for example E_RECOVERABLE_ERROR will or won't stop the execution based on the return value of the user defined error handler) as we don't wanna start sending http 500 responses for every notice and stuff.

oh, it seems we are explicitly checking for display_errors when setting the 500 response code:
http://lxr.php.net/xref/PHP_5_4/main/main.c#1154
I will ask the others on the internals list for the reason for this.

A workaround for those interested is the following:

register_shutdown_function(function() {
    $error = error_get_last();
    if ($error['type'] == E_ERROR) {
        header('HTTP/1.1 500 Internal Server Error');
    }
});

Be nice to see this fixed without this workaround though.

here is the thread I've started about this behavior:
http://www.serverphorums.com/read.php?7,965893
it turned out that we added the explicit display_errors check for not setting the http 500 response code because Internet Explore will show a custom error page for non-2xx responses if the length of the response body is less than an arbitrary threshold, hence it won't show the error message if we set the http 500.
I don't think that this change was a good idea back then, but it is possible that changing it now would cause more harm than good.
I will keep this ticket open until we either reach a consensus that this should be fixed in a future release, or should be kept as-is and the documentation is updated to reflect current behavior.

Ah yes, I remember that. The IE limit a minimum of 512 byte of data to show  the outputted data. Perhaps there could be an ini setting to choose if the status code will be 200 or 500, with the default being the current behaviour?

See also
https://bugs.php.net/bug.php?id=61417

+1

This is a BUG in my books. Until it is fixed, I can't simply tail an error log. Instead I'd have to go manually exercise every feature & invoke every code path in my app & painstakingly analyze the network responses of all my ajax calls to detect any possible errors. Horrible.

I would agree that this is a bug. If there has been a server error, we should not be returning a 200 response. If IE then does not display it, that is a problem for IE to look at. The wrong header causes a lot of problems, especially for AJAX>

Not just `display_errors = off`. I believe this effects `display_errors = stderr` as well for similar reasons.

I can't believe this hasn't been solved yet. It has been more than 5 years people! RFC 2616 is very clear on proper HTTP status codes (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). If some obscure browser handles return codes improperly, that should be solved there, not in PHP. This is not 1990s anymore, IE is far from being a dominant browser anymore. 

So how about fixing this the right way? Just return status 5xx on parsing and similar errors, as recommended (SHOULD) by HTTP 1.1 protocol. It shouldn't be that difficult.

You can't completely fix this by the way http works.

    <?php
    echo 'x';
    ob_flush(); // http status code and headers are now sent to client
    eval('x=y'); // error detected here

no matter which technology stack, after you've  sent everything is 200 OK you can't signal the client something went wrong. You shouldn't monitor your service through status codes only because of this edge case. Monitor your logs.

Disagree with above commenter - HTTP status codes are *designed* for monitoring the status of web services. Saying check the logs assumes the user has access to the logs - could be a shared host without log access, a third-party's service, or monitoring from an external uptime checker.

Sure - if headers have already been sent, not a lot PHP can do about that (though a basic HTTP 500 warning message would be better than the current blank page). But at the moment it doesn't matter if headers have been sent or not - PHP fails to return the correct 500 status code, which just about every other stack manages just fine.

After reporting this over 5 years ago, and it was known long before that, I'm at loss how something so basic hasn't been fixed yet.

Also - output buffering is enabled by default, no? So doesn't matter if output already sent, the status code can be overridden surely? 

And again, even if headers already sent, at least get the string '500 Internal Server Error' (as would happen if display_errors was off) into the output so the user has some clue something went wrong. How does displaying *less* error information if 'display_errors=true' make any sense? ;)

Yes, just because 1% of programmers may be using ob_flush() doesn't mean the other 99% are. Most PHP frameworks (Zend, Symfony, Silex) use some sort of controller that returns a response at the end of the request only. Specifically this is a big issue for ajax, which I'm pretty sure is impossible to use ob_flush() with, seeing as you need to build up a full response & output it at the end with json_encode() in its entirety.

I am experiencing this symptom under WampServer 2.5, which uses PHP 5.5.12. This happens even after disabling Xdebug, and even though display_errors is set to On. Is this caused by the same bug?

I agree with jonathan, josh and xmeltrut; a preference could be introduced, but the default behavior should not be the current behavior.

i've done this to solve the problem:
register_shutdown_function( "fatal_handler" );
function fatal_handler() {
    http_response_code (500);
}

I still experience this with XAMPP 5.6.30's PHP 5.6.30.

I'm trying to fix this.
Please review https://github.com/php/php-src/pull/3244.

And, Xdebug have same bug. If you are interested, see https://github.com/xdebug/xdebug/pull/420

Note that this may sometimes be down to the CustomLog format in apache. For example '%>s' can (correctly) yield a 403 in the access log whereas just '%s' may record a 200 even when the status code of the response was something else.

Just so you know, I had this same issue and I had to change my "error_reporting" value to the resolved integer value 
("E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED" -> 30711) 
[Based on this: https://www.php.net/manual/en/errorfunc.constants.php] 
since I'm trying to use an environment variable within the configuration file and it doesn't seem to resolve the constants properly.

in php 8.2 it returns a 200 response code even if using header and http_response_code

<?php

register_shutdown_function('shutdown_handler');

echo "Hello";

while(true) $data .= str_repeat('#', PHP_INT_MAX);
    
function shutdown_handler()
	{
	header($_SERVER['SERVER_PROTOCOL'].' 500 Internal Server Error', true, 500);
	http_response_code(500);
	print_r(error_get_last());
	}