When a symbolic link is broken (points to a non-existent file), the ErrorDocument specified in the VirtualHost section is returned instead of the ErrorDocument specified in the Directory section. Using out-of-the-box Unbutnu 8.04 server running Apache httpd 2.2.8. Did not touch anything but Virtual Host config. Here is the complete Virtual Host config: NameVirtualHost * <VirtualHost *> ErrorDocument 403 "Vhost 403" DocumentRoot /var/www/ <Directory /> ErrorDocument 403 "root 403" Options FollowSymLinks AllowOverride All </Directory> <Directory /var/www/> ErrorDocument 403 "/var/www 403" Options Indexes FollowSymLinks MultiViews AllowOverride None </Directory> </VirtualHost> I then went to /var/www which already had an index.html file in it and ran the following commands: cp index.html noperm.html chmod a-r noperm.html ln -s noperm.html goodlink.html ln -s broken badlink.html This means: * index.html is a valid, readable file * noperm.html is a valid file but httpd does not have permission to read it * goodlink.html is a valid symbolic link to noperm.html * badlink.html is a symbolic link to a non-existent file in the same directory Expected result: http://localhost/index.html returns the contents of index.html http://localhost/noperm.html returns "/var/www 403" and status code 403 http://localhost/goodlink.html returns "/var/www 403" and status code 403 http://localhost/badlink.html returns "/var/www 403" and status code 403 (I would actually prefer that badlink returns status code 404, but that is a battle I am not going to fight right now.) Actual result: Index, noperm, and goodlink work as expected. http://localhost/badlink.html returns "Vhost 403" and status code 403 Note: setting EnableSendfile off does not change the results.
I forgot to mention this may be related to Bug 28515
IIUC The inaccessible link target stops the server from associating any file with the current request, so the per-directory config is not applicable to the error response.
Could you perhaps make this a feature request rather than "wontfix"? I think the proper error handling of a broken symbolic link should be to handle it as a missing file in the same directory and with the same name as the symbolic link itself. It should return a 404 as configured for that directory.