httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Date Sun, 27 Jan 2002 03:36:25 GMT
"William A. Rowe, Jr." wrote:

> >
> > [gregames@daedalus gregames]$ ls
> > /www/
> > CVS             v3.2.3          v3.2.4-beta-1   v3.3.old
> > v3.1.1          v3.2.4          v3.3
> >
> > The backtrace I posted showed that apr_filepath_merge's addpath arg was
> > "builds/tomcat/release/v3.1/v3.1.1/v3.1.1/v3.1.1/..."  This comes from
> > r->filename in ap_directory_walk.  That seems odd in a few ways, beside the ever
> > growing bogus path.
> >
> > * why would we try to negotiate at all, when the only candidates are
> > directories, not files?
> BINGO.  /builds/jakarta-tomcat/release/v3.2 [path info = /bin/]

yep.  and path_info is key

> ... file not found.
> Not found?  We attempt to negotiate.

> Any which way, you are on to something, Greg, and it has nothing to do with the
> redirection aspect, or autoindex, IMHO.  But sub_req_lookup_dirent is also suspect.

yep. check out my commit for ap_sub_req_lookup_dirent.  That stops the loop and
produces a 404, as it should.

Let's say the original uri was /builds/jakarta-tomcat/release/v3.2/bin/ .
directory_walk does it's thing, and we end up in read_types_multi with
r->filename==.../release/v3.2 and path_info == /bin/ .  It reads the release/
dir, sees the entry for v3.2.3, and decides it's a partial match so it fires up
a dirent subrequest.  That was enough to kick off the near infinite recursion.

ap_sub_req_lookup_dirent created a subrequest with a filename that made sense
(.../release/v3.2.3 in this example) but the new uri was totally bogus.  It just
appended the name of the dirent to the end of the original untouched uri,
yielding .../release/v3.2/bin/v3.2.3 for the new uri.  It has been doing that
for months, but since process_request_internal knows it's a file subrequest, it
didn't used to matter.  When fixup_dir started running uri subrequests on these
guys, all of a sudden the bogus uri mattered.  


View raw message