DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=28173>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28173 Customizable error responses don't work the way they are intended to. Summary: Customizable error responses don't work the way they are intended to. Product: Apache httpd-2.0 Version: 2.0.49 Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Core AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] According to my understanding of customizable error responses they can be divided into two distinct features. * The first feature is *localization*, which is accomplished by editing the files found in the 'error' directory in the 'ServerRoot', i.e. by default in '/usr/local/apache2/error'. * The second feature is *appearance*, which is accomplished by editing the files found in the 'include' subdirectory to the 'error' directory mentioned above, i.e. by default in '/usr/local/apache2/error/include'. To enable these features one has to uncomment the customizable error related directives in the 'httpd.conf' file. E.g. like this: ... Alias /error/ "/usr/local/apache2/error/" <Directory "/usr/local/apache2/error"> AllowOverride None Options IncludesNoExec AddOutputFilter Includes html AddHandler type-map var Order allow,deny Allow from all LanguagePriority en cs de es fr it nl sv pt-br ro ForceLanguagePriority Prefer Fallback </Directory> ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var ErrorDocument 403 /error/HTTP_FORBIDDEN.html.var ErrorDocument 404 /error/HTTP_NOT_FOUND.html.var ErrorDocument 405 /error/HTTP_METHOD_NOT_ALLOWED.html.var ErrorDocument 408 /error/HTTP_REQUEST_TIME_OUT.html.var ErrorDocument 410 /error/HTTP_GONE.html.var ErrorDocument 411 /error/HTTP_LENGTH_REQUIRED.html.var ErrorDocument 412 /error/HTTP_PRECONDITION_FAILED.html.var ErrorDocument 413 /error/HTTP_REQUEST_ENTITY_TOO_LARGE.html.var ErrorDocument 414 /error/HTTP_REQUEST_URI_TOO_LARGE.html.var ErrorDocument 415 /error/HTTP_UNSUPPORTED_MEDIA_TYPE.html.var ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var ErrorDocument 501 /error/HTTP_NOT_IMPLEMENTED.html.var ErrorDocument 502 /error/HTTP_BAD_GATEWAY.html.var ErrorDocument 503 /error/HTTP_SERVICE_UNAVAILABLE.html.var ErrorDocument 506 /error/HTTP_VARIANT_ALSO_VARIES.html.var ... ./. After restaring apache, if one triggers an error, e.g. by creating a READ-PROTECTED file in the 'DocumentRoot' directory and then trying to access that file, a customizable error response (see below) is displayed instead of the generic error response. > Access forbidden! > > You don't have permission to access the requested object. It is either read-protected or not readable by the server. > If you think this is a server error, please contact the webmaster. > Error 403 > hostname > Sat Apr 03 01:16:27 2004 > Apache/2.0.49 (Unix) All this is okay so far. According to the information in the default 'httpd.conf' (httpd-std.conf) it's also possible to specify another location for the "appearance" files, i.e. for the files 'bottom.html', 'spacer.html', and 'top.html' which by default are found in sub-directory 'include' of directory 'error'. This following information can be found in the 'httpd.conf' file: # You can modify the messages' appearance without changing any of the # default HTTP_<error>.html.var files by adding the line: # # Alias /error/include/ "/your/include/path/" # # which allows you to create your own set of files by starting with the # /usr/local/apache2/error/include/ files and copying them to /your/include/path/, # even on a per-VirtualHost basis. Now, let's *prove* the statement made in the subject of this bug report, i.e. that "Customizable error responses don't work the way they are intended to". In order to manifest this, instead of creating an alternative directory with the "appearance" files just move the 'include' directory to the same level as our 'error' directory AND at the same time rename it, e.g. 'error-include'. Now, because we have moved them out of the original directory hierarcy of 'error' they now no longer inherit the directives speified for 'error', and therefore we must apply an explicit "Directory" directive for our moved 'error-include' directory. This is can easily be accomplished by copying the "Directory ..." directive block for 'error' and just changing '.../error' to read '.../error-include'. In addition, according to the information in 'httpd.conf' (see above) we now have to add the 'Alias /error/include/ "/usr/local/apache2/error-include/' directive to our 'httpd.conf' file. I.e. in addition to before our 'httpd.conf' file now also contains: ... Alias /error/include/ "/usr/local/apache2/error-include/" <Directory "/usr/local/apache2/error-include"> AllowOverride None Options IncludesNoExec AddOutputFilter Includes html AddHandler type-map var Order allow,deny Allow from all LanguagePriority en cs de es fr it nl sv pt-br ro ForceLanguagePriority Prefer Fallback </Directory> ... ./. After restarting the apache server, and triggering an error, e.g. as described above, we will receive an error response, but this time something like: [an error occurred while processing this directive] You don't have permission to access the requested object. It is either read-protected or not readable by the server. [an error occurred while processing this directive] NOTE: Don't leave the original sub-directory 'include' in 'error', or this will be used and you might not notice the problem and think everything works just fine. If you leave it in place, you can for example modify the background for the error response in 'top.html', e.g. to #FF0000 instead of #FFFFFF, to make it obvious which "include" directory is used. *Eventually* once this BUG has been corrected to handle the case where the "include" directory has been moved, you need to make sure that the case where the original "include" directory is left in place, but is overridden by an alias, also works. (And that it works when 'ServerRoot' is different from '/usr/local/apache2', which actually was the case when I noticed this problem in the first place). One last thing; I guess that this is a NEW FEATURE REQUEST though!? IMHO, it should be possible to modify the appearance of the "generic" error response messages too. Why not in the same way as for these customizable error responses? By just defining that 'Alias /error/include/ ...', and if the cusomized documents, i.e. 'bottom.html', 'spacer.html', and 'top.html' are found they're used, otherwise fall back to how it is Best Regards, Rolf Sponsel Ps. This is probably not only a SPARC/Solaris issue, but that is where is have verified the problem. Please adjust the 'Platform' and 'OS' accordingly. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
