httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Date Thu, 24 Jan 2002 17:01:06 GMT
Greg Ames wrote:

> I don't remember seeing a fix for the recursive subrequest loops involving
> mod_negotiation.  

some more info on this problem.  gdb refuses to produce a decent backtrace from
the coredumps, maybe because of the unusual depth of the call stack.  So I had a
hard time getting any meaningful info that way.  But we do have the backtrace
from when I attached gdb to a live looping process - the message ID is in the
STATUS file (thanks, Justin).

So I vi'd the 4 dumps, looking for the input buffers.  They all reference host:
jakarta.apache.org, and the request lines look very similar:

GET /builds/tomcat/release/v3.1/bin/   <== two of these
GET /builds/tomcat/release/v3.2/bin/
GET /builds/jakarta-tomcat/release/v3.2/bin/

/builds/tomcat/ is redirected to /builds/jakarta-tomcat/ via an .htaccess file,
so the bottom two refer to the same thing.  All of these refer to paths that no
longer exist:

[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?
* 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.
* 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.

Greg

Mime
View raw message