Edit report at https://bugs.php.net/bug.php?id=50921&edit=1
ID: 50921
Comment by: chealer at gmail dot com
Reported by: phpbug at starurl dot com
Summary: '200 OK' HTTP status despite PHP error
Status: Re-Opened
Type: Bug
Package: HTTP related
Operating System: *
PHP Version: 5.2.12
Block user comment: N
Private report: N
New Comment:
I still experience this with XAMPP 5.6.30's PHP 5.6.30.
Previous Comments:
------------------------------------------------------------------------
[2017-10-06 13:21:05] antoine dot gilabert at gmail dot com
i've done this to solve the problem:
register_shutdown_function( "fatal_handler" );
function fatal_handler() {
http_response_code (500);
}
------------------------------------------------------------------------
[2016-07-12 18:05:00] chealer at gmail dot com
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.
------------------------------------------------------------------------
[2015-12-14 17:31:59] josh dot ribakoff at gmail dot com
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.
------------------------------------------------------------------------
[2015-12-14 09:27:56] phpbug at starurl dot com
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? ;)
------------------------------------------------------------------------
[2015-12-14 09:17:31] phpbug at starurl dot com
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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=50921
--
Edit this bug report at https://bugs.php.net/bug.php?id=50921&edit=1