Bug 245483

Summary: Bogus "recursive" errors
Product: Red Hat Enterprise Linux 4 Reporter: Jiri TRAVNICEK, alias JITR {temporarily not reading bugmail} <travnicj-priv>
Component: httpdAssignee: Joe Orton <jorton>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 4.5CC: fnadge
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: Consequence: Fix: Result:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-02-16 13:57:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
proposed fix none

Description Jiri TRAVNICEK, alias JITR {temporarily not reading bugmail} 2007-06-23 21:56:44 UTC
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.)

Comment 1 Jiri TRAVNICEK, alias JITR {temporarily not reading bugmail} 2007-06-23 21:56:44 UTC
Created attachment 157701 [details]
proposed fix

Comment 2 Joe Orton 2009-08-14 12:01:14 UTC
This fix has been in RHEL5 forever; proposing for backport.

Comment 6 Florian Nadge 2011-01-13 13:16:37 UTC
Please be so kind and add a few key words to the technical note of this
bugzilla entry using the following structure:






Comment 7 Florian Nadge 2011-01-13 13:16:37 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    New Contents:




Comment 8 errata-xmlrpc 2011-02-16 13:57:32 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.