Edit report at https://bugs.php.net/bug.php?id=50921&edit=1
ID: 50921
Comment by: josh dot ribakoff 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:
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.
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2015-12-12 22:17:32] http at sendspamhere dot com
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.
------------------------------------------------------------------------
[2015-11-29 21:32:21] anzenews at volja dot net
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.
------------------------------------------------------------------------
[2015-11-29 06:28:37] admin at mcnaughton dot media
Not just display_errors = off. I believe this effects display_errors =
stderr as well for similar reasons.
------------------------------------------------------------------------
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