Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Apache's ErrorDocument directive does not redirect

I have a bunch of ErrorDocument directives in my .htaccess file in order to catch almost all the possible errors Apache can throw at a user, and to redirect said user to my error controller which would then render the error in a more user friendly manner. However, it does not seem work.

For instance, when I enter an invalid URL like mysite.com/""##$##$! I always get Apache's default 403 error message, instead of a redirect to my errors.php file. Below is the directive I'm using. Do I need to do anything else to make it work? (AllowOverride All is set)

   ErrorDocument 403 /errors.php

If this is the wrong way to approach absolute custom error handling, please let me know, I would appreciate a nudge in the right direction.

Thank you!

Edit: Oh, just thought I'd mention this. I wrote my own MVC structure for redirecting the request, and it works well. From within PHP, if a user requests a nonexistant URL, my own 404 error will fire just fine (or whatever other error I have defined). So basically, if I enter mysite.com/!!!! into the URL, it will work and I get a 404. However, whenever I start a request with the double quote character, the default Apache 403 error fires. Odd. Also, a 500 error will fail to redirect to errors.php as well, and will simply return a default Apache 500 screen (for instance, when testing with header("HTTP/1.0 500 Internal Server Error");die();).

Edit 3: I just tried placing ErrorDocument 200 "message" in my .htaccess file and nothing happened, any page I open opens normally. Worst case scenario, this should get stuck in an infinite loop. Best case scenario, it should output "message". It did neither, it simply ignored ErrorDocument. Apache's Access Log notes a normal 200 OK header, and yet it was completely ignored by .htaccess.

like image 225
Swader Avatar asked Apr 23 '11 16:04

Swader


1 Answers

A few different mis-conceptions in the question. The following PHP code:

header("HTTP/1.0 500 Internal Server Error");
die();

Will never trigger an Apache error page - it's triggering your browser's default error page. Once control has been given over to PHP, it does not go back to Apache for error handling.

ErrorDocument only works for error codes, not success codes. It's in the docs

Syntax: ErrorDocument error-code document

http://httpd.apache.org/docs/current/mod/core.html#errordocument

If you were mistaking one kind of browser error page for a server error, then that might be the cause of your main problem too. Unless your custom error handler outputs a certain amount of data, some browsers will always show their own error pages. Make sure your output is at least a few kilobytes in size.

The cause of your problem is most likely just Apache's built-in behavior combined with your choice of test URLs. From the ErrorDocument docs:

Although most error messages can be overriden, 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.


Edit: How to simulate a 500 error in Apache. My first thought was syntax errors in .htaccess, but this wont trigger custom error handlers. The easiest way I found was to enable CGI in .htaccess by adding these lines:

ErrorDocument 500 /500.php
Options +ExecCGI
AddHandler cgi-script .pl

And then adding a perl script that crashes:

#!/usr/bin/perl
safasfdsfdd_(*EYFIUOBAF(_*AS^FD_(*AWHD{

You will need to make sure the perl script is executable by apache's user. This shows my custom 500 handler.

However, you're very unlikely to ever trigger an Apache 500 when using PHP, so this probably isn't a useful test.

like image 123
Cal Avatar answered Sep 21 '22 12:09

Cal