PHP Emitting 500 on Errors - Where Is This Documented

PHP emitting 500 on errors - where is this documented?

Not sure, but this may have been added in PHP 5.2.4:

• Changed error handler to send HTTP 500 instead of blank page on PHP errors. (Dmitry, Andrei Nigmatulin)

There is also this discussion on the internals list that might be related:

• [PHP-DEV] FW: php fastcgi

Quoting:

Current time most PHP instalations use setting 'display_error=0'.
This setting hides errors from user but may send to him just a blank page.

The proposed patch sends HTTP 500 response on errors instead of blank pages.
The pages that already wrote something are not affectd.

Any objections or additions?

and the proposed solution/patch seems to be shown here:

• http://www.mail-archive.com/internals@lists.php.net/msg28557.html

Display 500 error on any error in apache

Assuming that you don't only want to send a 500 header (which is easy), but really trigger a 500 error in Apache's system, there seems to be no trivial solution.

According to this question, it is PHP's default behaviour since PHP 5.2.4 if:

1. a fatal error occurs and
2. the document body is empty (Gordon found the changelog entry here).

I'm not sure how reliable this behaviour is long term (i.e. when PHP 6 comes up etc.). It's not a much advertised feature.

Other than that, I know of no way of provoking a 500 once the script runs. I asked something similar for 404s once. The answer provided there (redirecting to a predefined URL, and sending a 500 header) may be the best you can get - although that of course won't be logged.

Interaction between display_errors and Parse Errors: HTTP 500 still generated

The reason for this is as follows:

When PHP sees the closing ?> tag, it adds an implicit semi-colon. This allows for syntax like this:

<?php echo "something" ?>

Why is this significant?

Because it means that when you have the closing tag, your stray a is actually seen as a;.

This difference is enough for PHP to have a go at parsing it. It doesn't recognise it, so it guesses that it's an unknown constant, and you get the notice message you see.

Without the closing tag, and without a semi-colon, PHP sees an unterminated line of code. This is a syntax error; PHP can't parse it at all, so it gives up.

Hope that explains the difference.

(on a side-note, that whole unknown-constant-so-I'll-assume-a-string thing is one of PHP worst mistakes. It's there for historical reasons, but I really hope they deprecate it at some point in the future; it leaves code wide open to horrendous bugs caused by a minor typo)

When PHP Fatal error happens, Nginx reports HTTP Error 500 to browser

Found it!

As of PHP 5.2.4, the default is now to cause a 500 error, because the alternative is an empty page.

Other discussions suggest that this behavior can not be changed for the "PHP Fatal" error type, which don't flow through the normal error handler routines and can not be caught or stopped.

500 error when downloading files over 63MB

Resolution was simple (after hours of work).

php_value output_buffering 0

added to Apache virtual host config.

Seems that, regardless of what ob_get_level() said, output buffering was taking place. In other words, just the option to use output buffering is enough for it to affect PHP memory use.

Is a HTTP 500 Error normal to display as a result from a semicolon omission in PHP?

Semicolons are almost always required in PHP. Omitting them results in a parse error which will cause the server to return a 500 error. So to answer your question it is a result of the languages design, not your config.

Ajax got 500 Internal Server Error when using json_encode()

Thanks to @vivek_23 I have realized the problem was not from my code (since the code ran fine in localhost) but my remote server. The PHP in my remote server didn't support JSON.

To anyone having the same problem:
You can run

var_dump(function_exists('json_encode'));

and see if it returns true or false. You can also run phpinfo() to see if there is a section where it said "json support: enabled". Seeing JSON in "Module Authors" section doesn't mean anything.

Since my remote server powered by CentOS, I downloaded a JSON package:

yum install php-json.x86_64

and it works.

---

Related Topics