I'm running Apache 2.2.15 with PHP 5.3.2, 'display_errors' disabled, 'display_startup_errors' disabled, 'log_errors' enabled.
Inside my setup (and so i contemplate it a typic), PHP aborts on fatal errors, that is good, and sets HTTP status code to 500. Fatal errors include E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR, E_USER_ERROR and, most likely, E_RECOVERABLE_ERROR (cannot trigger it myself, so can't easily check what goes on). It may be beneficial it does set the code to 500, because It may be the right factor to complete - clearly in case your script consists of syntax errors and/or does not do what should really do at runtime, it's a server error, when we consider PHP area of the server.
Now, this is actually the important part:
Anyway, I've now installed XDebug to trace errors better, but I can tell that now, regardless of error, despite the fact that the script aborts as before on fatal errors, the HTTP status code is definitely 200. This breaks my client that 'talks' to Apache/PHP via HTTP :
Also, setting display_errors to On/1, makes PHP no more set HTTP status code to 500 and exhibits the identical behavior just like XDebug above.
I'm greatly determined by reliable status code behavior here, which all leads me to think it's some type of fluke or random like weather.. or shall we be held missing something?
There's your blog publish which oulines the problem: http://talideon.com/weblog/2008/02/php-errors.cfm
In my opinion, I've disabled XDebug, seeing because it is what can cause unhealthy behavior to begin with. I only tried on the extender for stack tracing anyway, and today make use of a custom error handler for your rather. Also, the linked article comes from 2008, apparently PHP does set HTTP status code to 500 instantly nowadays. It will here. Without XDebug, obviously.
I suppose you're utilizing a custom error handler to emit the 500.
I'm not sure XDebug that well, but based on this article, it registers its very own error handler, most likely overriding yours along the way:
Please be aware the extended error display of xdebug doesn't work should you define a custom error handler using register_error_handler(). The reason being xdebug internally uses exactly the same mechanism. When your scripts make use of a custom error handler, you are able to still make use of the function xdebug_get_function_stack() to output the stack trace inside your custom error handler.
However, for production use, you will not activate XDebug anyway, are you currently?
For why a 200 is output whenever you activate
display_errors(), which i do not understand. Are you able to publish your custom error handler function to check out?