htaccess ErrorDocument 500 not working

Question

I have a site whose .htaccess file contains:

ErrorDocument 404 /errors/404.html
ErrorDocument 500 /errors/500.html

The 404 redirect works just fine, but when I encounter a 500 Internal Server Error, it gives the default Internal Server Error message as opposed to /errors/500.html. It also says

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

More info: I can get it to throw 500 if I type a trailing slash on a .html page that has had the ".html" removed by the remaining part of the htaccess file (e.g. if I try to navigate to http://example.com/test/ where test is actually test.html, then I get an internal server error):

#example.com/page will display the contents of example.com/page.html
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^(.+)$ $1.html [L,QSA]

#302 from example.com/page.html to example.com/page
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /.*\.html\ HTTP/
RewriteRule ^(.*)\.html$ /$1 [R=302,L]

Answer 1

I would try two things -

1. Check permissions of 500.html (try setting it to 777 to be very sure - modify it later).

2. Try 500.htm (or 500.txt) instead of 500.html (just to be sure that your other rules in htaccess are not messing up with the ErrorDocument 500.html page). Also, remember to change the htaccess ErrorDocument rule to 500.htm (or 500.txt).

Also, as per http://httpd.apache.org/docs/2.4/mod/core.html#errordocument

Although most error messages can be overridden, there are certain circumstances where the internal messages are used regardless of the setting of ErrorDocument. In particular, if a malformed request is detected, normal request processing will be immediately halted and the internal error message returned. This is necessary to guard against security problems caused by bad requests.

Try some other ways to simulate 500 error.

Answer 2

but when I encounter a 500 Internal Server Error, it gives the default Internal Server Error

The problem is that custom 500 error documents defined "late" in .htaccess simply don't get triggered for the majority of server errors - which is what's likely happening here. As Aakash has already quoted, this may come under the realm of a "malformed request". If you check your error log it should state: "core:error".

You stand a better chance of the custom 500 error document being served if it is defined "early" in the main server config (or VirtualHost container).

In fact, it is a bit tricky to simulate a real error that will trigger the custom 500 error document defined in .htaccess.

However, you can manually trigger a 500 error, which will call your custom error handler with something like the following:

RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^ - [R=500]

The check against the REDIRECT_STATUS env var ensures that the internal request for the error document itself does not trigger another 500 error, but a direct request for the error document would also trigger a 500 error. This check is not necessary if you already have an exception in place for error documents.

Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.

This does literally mean that in addition to the 500 error that resulted from the initial request, another 500 error was encountered when trying to serve the custom error document (that is called via an internal subrequest).

The custom error document itself is also processed by the Apache config/.htaccess.

Generally, exceptions need to be made for custom error documents so they can be served without additional processing.

More info: I can get it to throw 500 if I type a trailing slash on a .html page that has had the ".html" removed...

Not sure that this is really part of your question, but this 500 error is the result of a rewrite loop. Specifically:

RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^(.+)$ $1.html [L,QSA]

Request: http://example.com/test/ (with the extra slash)

In this case the %{REQUEST_FILENAME} is /path/to/test (no trailing slash), so the condition %{REQUEST_FILENAME}.html -f is true (/path/to/test.html does exist).

However, the URL-path that is captured by the RewriteRule pattern does contain the trailing slash ie. test/ - it is not the same as the REQUEST_FILENAME in this instance. So the URL gets incorrectly rewritten to test/.html.

And the rewriting starts over again from the top (because the URL has changed)... test/.html.html, test/.html.html.html, etc. (Because the REQUEST_FILENAME is always /path/to/test.)