From: "Greg Ames" <[EMAIL PROTECTED]> Sent: Thursday, January 24, 2002 11:01 AM
> Greg Ames wrote: > > > I don't remember seeing a fix for the recursive subrequest loops involving > > mod_negotiation. > > 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? Ack - that's twisted. > * it looks like we might be triggering some 1.3 negotiation behavior, where any > extention under the sun is a match. We use MultiviewsMatch Handlers, so .asis > and .cgi extentions do not need to be specified in the URI. Of course. This is as-desired, no? > * why do we see /builds/tomcat/ rather than /builds/jakarta-tomcat/ in > r->filename? I would think the redirect would happen early, and subsequent > filenames would contain the new path. Probably not important, because we got > the same loop when jakarta-tomcat was part of the original URI. Remember one bit, when I modified mod_dir, it now acts immediately using the fast_internal_redirect logic instead of the old logic in some cases. I'm certain we are hitting just such a case, and the two of them, together, have a serious issue. I'm sorry I've had a 50 hour week [yes - not yet Friday even] so I just haven't been able to look at this as promised. But I'm certain there is something 'interesting' in the points you made - a redirect to something absent, etc, that will help point us at the right direction; good catch! Bill
