DO NOT REPLY [Bug 28173] New: - Customizable error responses don't work the way they are intended to.

[bu...@apache.org]

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: bugs@httpd.apache.org
        ReportedBy: Rolf.Sponsel@kstr.lth.se
                CC: Rolf.Sponsel@kstr.lth.se


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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org