Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <01a201c1a6cc$4bb002d0$94c0b0d0@v505>
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: <dev@httpd.apache.org>
References: <3C4EEE20.3090804@apache.org> <3C4F03B9.E344EB9A@remulak.net>
 <3C503DD2.49038952@remulak.net>
Subject: Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Date: Sat, 26 Jan 2002 18:46:26 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

From: "Greg Ames" <gregames@remulak.net>
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/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/]

... 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 :)

Bill