August 23, 2007
PHP Now Using Proper HTTP Status Codes on Error
I'm not sure if I have blogged about this before, but one of my biggest complaints about PHP is how it dies. If it encounters a serious error, like a parse error, it just stops and there is nothing you can do about it. If this happens on a hosted web site, you get a blank page served with the HTTP status code of 200. Completely useless to remote connections. Marginally useful is the PHP error logging to isolate the problem, but even then...
I was glancing through the upcoming PHP 5.2.4 changes and saw this:
Changed error handler to send HTTP 500 instead of blank page on PHP errors. (Dmitry, Andrei Nigmatulin)
Proper HTTP status code usage! To someone who loves utilizing HTTP to its fullest, this is wonderful news! Although I haven't seen documentation for this new "feature", I assume this means that I can finally guarantee that if my web service emits a 200 status code, the response is well-defined. I hope so, or my griping will persist...
You can ping this entry by using http://blog.case.edu/gps10/mt-tb.cgi/15040 .
It can send the proper status code. But can it send a human readable page back to a end user?
Speaking of HTTP codes…have you seen all the paid websites starting to use the 402 lately? I see it everywhere! It is not even a part of the 1.1 standard. Just ‘reserved for future use’. I guess this is the future!
Haven't tested it, but I would imagine that if PHP spits out a proper status code then your webserver should be able to capture it:
ErrorDocument 500 error.html
Granted it won't give you the exact error, but at least you can present a useful error message to the user.