Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
Date: 5 Apr 2004 21:36:04 -0000
Message-ID: <20040405213604.24611.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 28173]  -
    Customizable error responses don't work the way they are intended to

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


------- Additional Comments From Rolf.Sponsel@kstr.lth.se  2004-04-05 21:36 -------
Joshua,

There seems to be an issue, although minor, with customizable error responses
despite all. I decided to post it in this thread as it's slightly related and
definitely covered by the summary of this report.

Forget all that we've been discussing earlier in this thread.

It's about error responses in an virtual hosts environment, and I've attached a
diff file showing the differences between the httpd-std.conf file and the
httpd.conf file I have used. It contains the minimal modifications required in
order to reproduce my observations.

Follow these steps to reproduce:

1). Create/use a default installation of apache httpd-2.0.49

2). In the DocumentRoot, i.e. htdocs, create a file, e.g. READ-PROTECTED-FILE,
and make sure it's not readable (just in order to have some file by means which
we can trigger the error).

3). Create 2 virtual hosts (by applying the provided diff in attachement 11147).
    Edit the virtual hosts' ServerName to something that suites your installation.
    Just for the sake of simplicity both virtual hosts do use the same
DocumentRoot (which is inherited from the default configuration).
    The first virtual host is supposed to generate a default error response, the
second is supposed to generate a customized error response as it has the 'Alias
/error/ ...' directive defined.
    (In my particular case the ServerName '192.168.0.1' refers to a gateway that
forwards the request to 192.168.0.100:80. You could use just any host alias of
192.168.0.100 instead. I've verified that)

4). Now, if you access that same read-protected file through either the first or
the second virtual host a 403 Forbidden error is triggered, which is expected.

The SECOND virtual server displays (just as it is expected to):

> 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
> 192.168.0.1
> Mon Apr 05 22:31:57 2004
> Apache/2.0.49 (Unix) 

The FIRST virtual server displays (which contains *additional* information to
what it usually does, i.e. if NO 'ErrorDocument' directive had been specified):

> Forbidden
>
> You don't have permission to access /READ-PROTECTED-FILE on this server.
> 
> Additionally, a 404 Not Found error was encountered while trying to use
> an ErrorDocument to handle the request.
>
> Apache/2.0.49 (Unix) Server at 192.168.0.100 Port 80

5). If you now comment out the ONLY ONE ErrorDocument directive specified in
your httpd.conf file, then the generic error response renders the expected
result (i.e. which is generated by default under normal conditions), i.e.:

> Forbidden
>
> You don't have permission to access /READ-PROTECTED-FILE on this server.
>
> Apache/2.0.49 (Unix) Server at 192.168.0.100 Port 80


Now, how does this impact an apache server installation?

This means that you do not get a "clean" default error response for a virtual
host *if* one or more virtual hosts enable and share one set of customized error
response documents. If you on the other hand do not share (i.e. define any
shared 'ErrorDocument ...' directives, then this is not an issue.

This raises the question what actually triggers the use of customized error
responses?

At least to me, it seems like it's the definition of any 'ErrorDocument'
directives. IMHO this shouldn't be the case. The 'ErrorDocument' directives
should only define the documents, not trigger/bind the use of them. Once again,
IMHO, the actual triggering/binding should occur when specifying the 'Alias
/error/ ...' directive; either in the default server, or withing any virtual host.


As I said before; this is *not* a big issue.
I just wanted to make sure that you were aware of this though.


Kind Regards,
Rolf Sponsel


Don't hesitate to ask for more information, in case you need.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org