httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Date Sun, 27 Jan 2002 00:46:26 GMT
From: "Greg Ames" <>
Sent: Thursday, January 24, 2002 11:01 AM

> 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).
> GET /builds/jakarta-tomcat/release/v3.2/bin/
> the bottom two refer to the same thing.  All of these refer to paths that no
> longer exist:
> [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/]

... file not found.

Not found?  We attempt to negotiate.  

Now, what's broke about /v3.2 ?  That is a danged good question, not one I have
an easy answer to.  Could we have a lingering 'is dir' status?  Good question.
I suspect that could be it; a recent OPTIMIZATION to dir_walk tells it to trust
the finfo if it's already present in the structure.

Now; we should be failing each of the v3.2.3, v.3.2.4, v.3.2.4-beta-1 items in
mod_negotiation, since they are directories.  BUT [here's the critical but] if we
polluted the request rec's finfo, then bang, we blew it.

Something smells here; maybe mod_negotiation now fails to test for 'is a dir',
maybe mod_negotiation also fails to wipe out the earlier path [v3.1 +/+ v3.1.1],
maybe the set-aside path_info was wrong.

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.

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

Exactly.  We should be triggering negotation (v3.1 and v3.2 not found).  
But we should be ignoring dirs.

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

Agreed this is somewhat irrelevant, at this moment :)


View raw message