#18824 [Bgs]: PHP should produce an appropriate status code when an error is encountered

ID: 18824 Updated by: rasmus@php.net Reported By: bugs.php.net@mnot.net Status: Bogus Bug Type: Feature/Change Request Operating System: unknown (maybe FreeBSD?) PHP Version: 4.2.2 New Comment: I still don't agree that this should be a default thing. An application level error is quite different from a server-level error. Most production sites should be redirecting all errors to a log file or some other mechanism. There can be runtime errors that occur that do not significantly impact users. In that sense I do not believe application level errors should be extended to the client. Perhaps an argument can be made for fatal php initialization errors that occur at the interface between the server and PHP. For example, how about a simple redirection script which sends a location header and either a 301 or a 302. Some logging code after the redirect fails for some reason. In normal operation, the user still gets redirected, but in your scenario this becomes a 500 and the script no longer works. Previous Comments: ------------------------------------------------------------------------ [2002-08-09 03:01:45] bugs.php.net@mnot.net IMP buffers, as does any other application using HTTP:Compress. > Also, consider that errors generally occur after some > valid content has been generated, and not sending this > in a valid response would make it considerably harder to > debug things. A 500 response can have a body just as easily as a 200 can. > If someone wants this functionality in buffered mode, > they could easily do it with their own error handling > function. It's not the person writing the application who would necessarily want this functionality; it's the consumer of the application. The idea is to be compatible with the Web architecture, and that means honoring the semantics of the protocols. Cheers, ------------------------------------------------------------------------ [2002-08-09 02:55:51] rasmus@php.net No, buffering is not that common. But even so, having the http status change depending on buffering would be quite inconsistent and would likely confuse the heck out of people. Also, consider that errors generally occur after some valid content has been generated, and not sending this in a valid response would make it considerably harder to debug things. If someone wants this functionality in buffered mode, they could easily do it with their own error handling function. ------------------------------------------------------------------------ [2002-08-09 02:31:02] bugs.php.net@mnot.net So is the correct status code output if the response is buffered? AFAIK a fair number of PHP applications use output buffering these days, so it would be useful to take advantage. ------------------------------------------------------------------------ [2002-08-09 02:15:54] rasmus@php.net You are assuming that PHP buffers all output before sending anything. That is an incorrect assumption. A fatal script error can occur long after the HTTP response headers have been sent. ------------------------------------------------------------------------ [2002-08-09 02:09:32] bugs.php.net@mnot.net I don't use PHP, I'm just a protocol weenie. I encountered the following from travel.yahoo.com tonight: HTTP/1.1 200 OK Date: Fri, 09 Aug 2002 06:02;01 GMT Connection: close Content-Type: text/html <br /> <b>Fatal error</b>: Cannot instantiate non-existent class: travel in <b>/home/y/share/htdocs/t/index.php</b> on line <b>19</b><br /> Fine, except that it gives a 200 OK status. The right thing would be to generate a 500 Server Error status; this indicates that something is wrong in a machine-understandable way, which is good. It shows up in the logfiles. Agents (like Google) understand that all is not well. Please modify PHP to generate appropriate status codes. 500 is just one example; have a look at RFC2616 for other status codes that you might want to map machine-understandable semantics to. Cheers, ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=18824&edit=1