"William A. Rowe, Jr." wrote: > > > > [gregames@daedalus gregames]$ ls > > /www/jakarta.apache.org/builds/jakarta-tomcat/release > > 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. Greg
