Bug 245483

Description of problem:

When an HTTP error (such as 403 Forbidden or 404 Not Found) is reported, it is
possible a bogus(!) `Additonally a <code> error was encountered while trying to
use an ErrorDocument to handle the request.'

This "recursive" error has appeared even without having any `ErrorDocument'
directives enabled.


Version-Release number of selected component (if applicable):

2.0.52-32.ent (2.0.52-32.ent.centos4)


How reproducible:

Always when the "right" conditions are satisfied (see below).



Steps to Reproduce:

Warning: The conditions for this error to appear are not completely clear to me.
I'll just try to describe what semed to "work" for me.

1. Enable the user-directory config by setting a `UserDir' directive (e. g. use
the default value `public_html').
2. Make sure there's a home directory which Apache has no permissions to reach.
It seems there must be both no permissions in the filesystem as well as no
permissions in the server config to access this directory (*).
3. Disable any possible `ErrorDocument' directives you may have (or just make
sure they do not point to the directories we forbid access to in the previous
steps so that the test is provable).
4. Make a request for a home directory Apache has no permission to access, e. g.
access an URL like `http://<hostname>/~<username>/'.
5. Check the error message returned.

(*) Plase note that in default RHEL config, there seems to be no deny-config for
`/', so this might have to be taken care of manually. Just add `Order
Allow,Deny' and `Deny from all' to the `<Directory />' section.

  
Actual results:

If the "constellation" is right, you should get the 403 error with a bogus
notice `Additonally a 403 error was encountered while trying to use an
ErrorDocument to handle the request.'


Expected results:

The 403 error shoudl be shown, but without the `Additonally a 403 error ...' note.


Additional info:

This seems to be a known bug in Apache Bugzilla -- #36090. Even though it's been
fixed over a year ago, the bugfix made it into the 2.2 branch only. It would
need to be backported to 2.0.

This bug may be considered very minor, but the error messages seem to be a bit
misleading for any sysadmin who cares. Additionally (if I recall correctly), an
occurence of "recursive" error prevented any existing custom error documents to
be served (even if they actually were accessible provided the "recursivity" is
really bogus), which might be undesirable.

Given the severity, this might not be of interest. On the other hand, I provide
a patch which was backported from ASF SVN. It was tested a bit and seems to fix
the problem. (I'm using it at the moment.)