ARTICLE AD BOX
Nowadays it's no more a problem - since 5.3 PHP learned at last to send 503 on error, not 200
Err, it seems it was 5.2.4:
Changed error handler to send HTTP 500 instead of blank page on PHP errors.
You need to set display_errors = off to make it work
I have the exact behavior on my windows Apache 2.4 with PHP 5.4.5
answered Jan 8, 2013 at 10:09
6 Comments
I've tested with PHP 5.3.10. A syntax error for example will still result in an 200 OK. Under which circumstances will PHP send the 503?
2013-01-08T16:34:07.573Z+00:00
Your update sounds great!! But it is still not working for me. I've tested with PHP 5.3.10-1ubuntu3.4. I used a simple syntax error page <? error for testing. display_errors is disabled. I still get a blank page and response code 200. I'm using the apache2 sapi. Do you know a php version / web server combination with that you can produce the 500 ?
2013-01-08T17:51:48.74Z+00:00
@YourCommonSense, do there exist ways to temporary override the 5.2.4 behavior, forcing it to show a blank page on PHP errors?
2013-07-22T16:22:59.523Z+00:00
@YourCommonSense, display_errors is 0 and the page is sending HTTP 500. can we override this behavior, forcing it to show a blank page instead?
2013-07-22T16:28:00.033Z+00:00
@Pacerier PHP does show a blank page. Whatever else decorations you may see, provided by either browser (most likely as most of them like to) or a web-server (needs a special tuning though). Try to request your page with a command-line agent like wget and see
2013-07-22T16:30:33.83Z+00:00
You can, of course, write your own error handler. However, not all PHP errors are catchable. For instance, a syntax error won't even allow your code to run, including your error handler.
To handle catchable errors, you can use the auto_append_file and auto_prepend_file directives to place your error handling code code.
Non-catchable errors are a different issue. If PHP runs as Fast CGI, it will automatically generate a 500 status code for you. However, you're probably running PHP through some other SAPI (such as Apache module). No idea about that, sorry. (I'll report back if I find something.)
3 Comments
Thanks for the quick answer! Yes I wrote a custom error- and exception handler, but you are right, the uncatchable errors are the problem. I'm googling on this..
2010-08-05T08:10:49.277Z+00:00
Whatever, it's sort of uncommon that such kind of fatal errors go live unnoticed, isn't it?
2010-08-05T08:22:45.143Z+00:00
syntax errors and other fatal errors can't be caught by any error handler
2010-08-05T15:37:36.08Z+00:00
Response headers are not sent until PHP echoes the first byte of response body. You can change headers (and the status code) in the mean time. Keeping that in mind, here is a solution:
Set your script to send a 500 response code at the beginning of script and 200 at the end. Here is an example:
header($_SERVER['SERVER_PROTOCOL'] . ' 500 Internal Server Error'); if (rand(0, 1) == 1) { die("Script terminated prematurely"); } header($_SERVER['SERVER_PROTOCOL'] . ' 200 OK'); echo "Success";Just ensure that 200 response code is set at only one location in your code.
Note: you can use http_response_code (PHP >= 5.4) instead of header.
2 Comments
Nice idea +1 :) But it will still send 200 OK if for example a (fatal) syntax error is thrown.
2013-01-08T16:36:06.4Z+00:00
At least on PHP >= 5.3.19 a script with syntax errors generates 500 error. No one would like to have such a script on a production server anyway.
2013-01-08T17:39:17.953Z+00:00
Explore related questions
See similar questions with these tags.
![Is procedural PHP a good approach for user registration and login system good for begginers? [closed]](https://stackoverflow.com/Content/Sites/stackoverflow/Img/apple-touch-icon@2.png?v=0f0cab681579)