httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: infinite recursive subrequests
Date Tue, 16 Oct 2001 21:05:09 GMT
"William A. Rowe, Jr." wrote:
> This fix to request.c (1.68) definately appears to have broken the server.
> I know you commented it was 'gross', but perhaps we walk the list of
> r->main->uri/filename or r->main->uri/filename on each subrequest...
> if we hit 'ourself' we die.

We could, but that's just a sanity check that shows us we're doing
something wrong elsewhere.
We need to fix the code that's generating and using the bad URIs in the
first place.  Maybe we should just wrap the infinite subrequest
recursion checks in #ifdef AP_DEBUG logic and go for it.  What do folks

> Just a thought.  I'd still like more details.  More inline.

> >
> > When I set up my ThinkPad to replicate the website, I decided
> > to ignore the bug database at first.  So I simply commented out the
> > VirtualHost definitions in my config file, and expect to
> > get errors for the bugs db URLs.  The latest chuck of daedalus's
> > production log I'm using for replay testing had a GET for
> > .  When the vhost lookup fails on
> > my TP, we set r->hostname to, which is the first vhost.
> > (seems odd, but that's a different issue.)  In's
> > doc_root, the only thing that matches index* is index.html , and I get
> > the subrequest recursion problem.

> I don't see how index.html then recurses?  Please explain?

ap_sub_req_dirent_lookup will end up generating recursive subrequests
with URIs of /index/full/index.html, when mod_negotiation is trying to
lookup filename <doc_root>/index.html.  Something (directory_walk ??)
trims back r->filename to the valid pieces of the path, but the URI
never gets trimmed to correspond.  That's fine when we just use the
filename, not fine when we use the URI.

> > But on daedalus, /www/ contains index.cgi .  /index from
> > the URI matches the index.cgi file, and the rest of the URI seems to be
> > used as parms for the cgi.  Therefore knowing where the last slash is in
> > the URI is insufficient to determine what's a directory and what's not,
> > and the fuzzy search for index* in doc_root is necessary to locate a
> > potential cgi.
> Could we have a broken PATH_INFO?  Sounds like the problem.  A user reported
> similar on 1.3.22 :(

We could indeed.  I see your patch for r->path_info and will play with


View raw message