You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Ames <gr...@remulak.net> on 2002/01/24 18:01:06 UTC
mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
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
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Jacek Prucia <ja...@7bulls.com>.
On Thu, 31 Jan 2002 12:42:56 -0500
"Joshua Slive" <jo...@slive.ca> wrote:
[...]
> In fact, this configuration looks terribly invalid. It should be
> RedirectMatch /build/tomcat/(.*)
> http://jakarta.apache.org/build.jakarta-tomcat/$1
> Or even better
> Redirect /build/tomcat/ http://jakarta.apache.org/build.jakarta-tomcat/
>
> We should be returning an error if the target argument to
> Redirect/RedirectMatch isn't an absolute URL.
That's the case with 1.3 and (after a quick check) also with 2.0. Inside add_redirect_internal() there's a check on second argument with ap_is_url() and if that test fails, server bails out with: Redirect to non-URL
However I think that sometimes it might make sense to have target an absolute URI, but that would trigger so called self-referenced redirect. Something that mod_dir already does. I know that behaviour of such redirect would depend on value of UseCanonicalName directive. On the other hand if that directive has bogus value, then mod_dir will not work anyway. Assuming people are setting ServerName and UseCanonicalName correctly, they can use something like:
Redirect /foo /path/to/bar
...to mean something like: redirect /foo to this_server/path/to/bar which might be usefull in some scenarios.
I've already prepared a patch for mod_alias to meet my own needs. It makes mod_alias accept absolute path as second argument to redirect and then at filename translation phase it just builds valid URL with ap_construct_url (the same thing mod_dir already does). If people are interested I can clean it up and send to list.
--
Jacek Prucia
7bulls.com S.A.
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Rodent of Unusual Size" <Ke...@Golux.Com>
Sent: Thursday, January 31, 2002 11:39 AM
> Greg Ames wrote:
> >
> > /builds/tomcat/ is redirected to /builds/jakarta-tomcat/ via an
> > .htaccess file, so the bottom two refer to the same thing.
>
> This actually exposes a new issue: invalid redirect fields.
>
> GET /builds/tomcat/ HTTP/1.0
> Host: jakarta.apache.org
>
> returns
>
> Location: /builds/jakarta-tomcat/index.html
>
> The 'index.html' is one problem, new since 2.0.28.
And were the original issue not misbehaving, this 'problem' you cite is
correct behavior.
E.g. both get /builds/tomcat/ and /builds/tomcat/index.html would return
Location: /builds/tomcat/index.html
which is a very appropriate use for the Location field [what is the location
we actually returned? index.html.]
BUT that's not what I see right now;
HEAD /builds/tomcat/ HTTP/1.0
Host: jakarta.apache.org
HTTP/1.1 302 Found
Date: Thu, 31 Jan 2002 18:33:37 GMT
Server: Apache/2.0.28 (Unix)
Location: /builds/jakarta-tomcat/
Connection: close
Content-Type: text/html; charset=iso-8859-1
> However, the invalid absoluteURI issue is present even back in 2.0.28.
>
> The relevant line in the .htaccess file is:
>
> RedirectMatch /builds/tomcat/(.*) /builds/jakarta-tomcat/$1
>
> Since there's no '[R]' flag, I'm not sure why this is forcing
> an external redirect, either, rather than keeping it internal
> and concealed from the client.
Sounds like the external redirect is really
/builds/jakarta-tomcat/ -> /builds/jakarta-tomcat/index.html
Just a hunch.
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Ian Holsman <ia...@apache.org>.
Is this a showstopper for a .31 roll ?
IMHO it shouldn't be
as the big browsers happily accept relative URL locations.
so while not RFC compliant it's not going to be crashing things
or stopping people from serving pages.
Joshua Slive wrote:
>>-----Original Message-----
>>From: Rodent of Unusual Size [mailto:Ken.Coar@Golux.Com]
>>
>
>>RedirectMatch /builds/tomcat/(.*) /builds/jakarta-tomcat/$1
>>
>>Since there's no '[R]' flag, I'm not sure why this is forcing
>>an external redirect, either, rather than keeping it internal
>>and concealed from the client.
>>
>
> You are confusing RedirectMatch with RewriteRule. Only the latter needs the
> [R].
>
> In fact, this configuration looks terribly invalid. It should be
> RedirectMatch /build/tomcat/(.*)
> http://jakarta.apache.org/build.jakarta-tomcat/$1
> Or even better
> Redirect /build/tomcat/ http://jakarta.apache.org/build.jakarta-tomcat/
>
> We should be returning an error if the target argument to
> Redirect/RedirectMatch isn't an absolute URL.
>
> Joshua.
>
>
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Joshua Slive wrote:
>
> What about a compromise for 1.3: Log it as an error but don't bork the
> request; just let it through with the bad location header?
Now that the issue has surfaced, it needs to be handled. I'm
-1 on a 'fix' that perpetuates RFC-noncompliant behaviour.
The minimalist 'right' fix is already in; the Best Thing Right Fix
is to issue a warning message and add the netpath if absent.
It's the figuring out of the correct netpath that sucks lithoi.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millenium hand and shrimp!"
RE: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Joshua Slive <jo...@slive.ca>.
> From: Rodent of Unusual Size [mailto:Ken.Coar@Golux.Com]
>
> Ian Holsman wrote:
> >
> > I don't think we should be forcing people into RFC compliance
> > like this.
>
> The compliance with the RFC isn't something we're forcing on
> people, it's something the server needs to do in its generation
> of Location fields.
What about a compromise for 1.3: Log it as an error but don't bork the
request; just let it through with the bad location header?
In reality, there probably aren't THAT many people who will be affected.
RedirectMatch is not used as much as Redirect (which already errors out
correctly).
Joshua.
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ian Holsman wrote:
>
> I don't think we should be forcing people into RFC compliance
> like this.
The compliance with the RFC isn't something we're forcing on
people, it's something the server needs to do in its generation
of Location fields.
> so I'm -0.9 on it we should be opening the bag of cats. If you can
> explain to me what the bag is I'll be happy to open it.
The bag is figuring out the correct prefix to attach. 'http' or
'https'? What's the hostname? How about the port?
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millenium hand and shrimp!"
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Ian Holsman <ia...@apache.org>.
Rodent of Unusual Size wrote:
> Ian Holsman wrote:
>
>>The fix you just put in will probably break a lot of configurations
>>
>
> They were broken as it stands; the documentation says 'must be
> a valid URI'.
>
yep.. but thats true, and it isnt RFC compliant, and no one should be
using it in a perfect world. but the problem is that it is a common
config mistake, and I'm thinking there are 1000's of sites that are
working hapilly on 1.3.23, that aren't going to work on 1.3.24
I don't think we should be forcing people into RFC compliance like this.
at the very least this should be done in post-config not at runtime.
so I'm -0.9 on it we should be opening the bag of cats. If you can
explain to me what the bag is I'll be happy to open it.
BTW.. looking at mod-rewrite it seems to be doing location redirects on
r->filename and they appear to be ok.. so I'm still not sure what is
going on here to make mod_alias's redirects not work.
>
>>is it possible to prefix the r->hostname to the relative URI instead?
>>
>
> Then you get into that whole UseCanonicalName bag of cats.
>
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Ian Holsman wrote:
>
> The fix you just put in will probably break a lot of configurations
They were broken as it stands; the documentation says 'must be
a valid URI'.
> is it possible to prefix the r->hostname to the relative URI instead?
Then you get into that whole UseCanonicalName bag of cats.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millenium hand and shrimp!"
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Ian Holsman <ia...@apache.org>.
Rodent of Unusual Size wrote:
> Rodent of Unusual Size wrote:
>
>>Yar; Redirect* should hork on invalid substitutions,
>>just as you say. I'll look at that one.
>>
>
> The culprit appears to be RedirectMatch, even back in 1.3.
>
> No, I don't think this stops a roll by any means -- but it
> *does* stop it from being GA.
>
The fix you just put in will probably break a lot of configurations
is it possible to prefix the r->hostname to the relative URI instead?
this would make existing configurations work, and would allow a simple
redirect work across virtual hosts (the 1.3 commit will force a seperate
redirectmatch in each vhost)
..Ian
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"William A. Rowe, Jr." wrote:
>
> > Rodent of Unusual Size wrote:
> >
> > No, I don't think this stops a roll by any means -- but it
> > *does* stop it from being GA.
>
> Is the bug in 1.3? Then what's the showstopper?
Apache, being a reference implementation of the HTTP RFCs, is
in violation of the protocol. Or was, until I fixed it.
> So it's a bug. It's no WORSE than 1.3. I'd love to see it fixed,
> but since it is the same back in 1.3, it doesn't keep 2.0 from being
> 'the best version available' - our general guideline for a GA release.
Because we did something wrong in a previous version doesn't
grant licence to continue doing it wrong, particularly when
the earlier versions were in error without being noticed. Once
it's been spotted, it takes a conscious decision to say, "Let's
ignore this protocol violation brokenness."
> So go fix it already :)
Done.
It's not just a matter of prefixing the substitution string
with the original net-path info; consider
RedirectMatch /foo/(.*) $1
where the expected incoming requests are for URIs like
'http://x.com/foo/http://bar.com/'. (And I've seen some
like this, alas.) Sticking the local netpath on the front
of the substitution string, which is valid as it stands,
will break it.
If someone wants to enhance fixup_redir() to do a check
for leading '/' after the alias lookup has been done, and
*then* add the prefix, that would be goodness. But that's
where the UseCanonicalName what's-the-right-netpath problem
comes in -- which took us months to get right.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millenium hand and shrimp!"
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Rodent of Unusual Size" <Ke...@Golux.Com>
Sent: Thursday, January 31, 2002 12:10 PM
> Rodent of Unusual Size wrote:
> >
> > Yar; Redirect* should hork on invalid substitutions,
> > just as you say. I'll look at that one.
>
> The culprit appears to be RedirectMatch, even back in 1.3.
>
> No, I don't think this stops a roll by any means -- but it
> *does* stop it from being GA.
Is the bug in 1.3? Then what's the showstopper?
So it stops any GA on 2.0, 1.3, 1.2 ... heck, we might as well put up
the 'out of business - go download NCSA' sign.
So it's a bug. It's no WORSE than 1.3. I'd love to see it fixed, but
since it is the same back in 1.3, it doesn't keep 2.0 from being
'the best version available' - our general guideline for a GA release.
So go fix it already :)
Bill
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Rodent of Unusual Size wrote:
>
> Yar; Redirect* should hork on invalid substitutions,
> just as you say. I'll look at that one.
The culprit appears to be RedirectMatch, even back in 1.3.
No, I don't think this stops a roll by any means -- but it
*does* stop it from being GA.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millenium hand and shrimp!"
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Joshua Slive wrote:
>
> You are confusing RedirectMatch with RewriteRule.
D'OH! (manipulative member dents anteriour cranium)
> In fact, this configuration looks terribly invalid.
Yar; Redirect* should hork on invalid substitutions,
just as you say. I'll look at that one.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millenium hand and shrimp!"
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Greg Ames wrote:
>
> Are we creating another migration task here?
Not any more. Although if a config has something completely
bogus, like
Redirect /foo ugly-non-abs_path
we'll throw a 500 server-side rather than the client
doing whatever client-specific thing it would otherwise
do (or not do) with it.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millenium hand and shrimp!"
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Ian Holsman <ia...@apache.org>.
Rodent of Unusual Size wrote:
> Rodent of Unusual Size wrote:
>
>>As things stand at this instant, maybe. If I can get the
>>netpath prefixing correctly, it will continue to function
>>as it does now (but w/o violating HTTP) and only issue a
>>warning message to the log.
>>
>
> Okey, I've got a handle on this now, I think; commit coming
> shortly for both 1.3 and 2.0.
>
do you want .31 to have this patch included in it?
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Rodent of Unusual Size wrote:
>
> As things stand at this instant, maybe. If I can get the
> netpath prefixing correctly, it will continue to function
> as it does now (but w/o violating HTTP) and only issue a
> warning message to the log.
Okey, I've got a handle on this now, I think; commit coming
shortly for both 1.3 and 2.0.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millenium hand and shrimp!"
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Greg Ames wrote:
>
> I glanced at the doc for RedirectMatch after Ken's commit, and
> didn't see any words about absolute URLs. Redirect has them though.
RedirectMatch refers to Redirect; inheritance. :-)
> What does the 1.3 code do?
If the completed substitution target isn't an absoluteURI,
it horks a 500.
> Are we creating another migration task here?
As things stand at this instant, maybe. If I can get the
netpath prefixing correctly, it will continue to function
as it does now (but w/o violating HTTP) and only issue a
warning message to the log.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millenium hand and shrimp!"
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Greg Ames <gr...@remulak.net>.
Joshua Slive wrote:
> In fact, this configuration looks terribly invalid. It should be
> RedirectMatch /build/tomcat/(.*)
> http://jakarta.apache.org/build.jakarta-tomcat/$1
> Or even better
> Redirect /build/tomcat/ http://jakarta.apache.org/build.jakarta-tomcat/
>
> We should be returning an error if the target argument to
> Redirect/RedirectMatch isn't an absolute URL.
I glanced at the doc for RedirectMatch after Ken's commit, and didn't see any
words about absolute URLs. Redirect has them though.
What does the 1.3 code do? Are we creating another migration task here?
Greg
RE: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Joshua Slive <jo...@slive.ca>.
> -----Original Message-----
> From: Rodent of Unusual Size [mailto:Ken.Coar@Golux.Com]
> RedirectMatch /builds/tomcat/(.*) /builds/jakarta-tomcat/$1
>
> Since there's no '[R]' flag, I'm not sure why this is forcing
> an external redirect, either, rather than keeping it internal
> and concealed from the client.
You are confusing RedirectMatch with RewriteRule. Only the latter needs the
[R].
In fact, this configuration looks terribly invalid. It should be
RedirectMatch /build/tomcat/(.*)
http://jakarta.apache.org/build.jakarta-tomcat/$1
Or even better
Redirect /build/tomcat/ http://jakarta.apache.org/build.jakarta-tomcat/
We should be returning an error if the target argument to
Redirect/RedirectMatch isn't an absolute URL.
Joshua.
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Greg Ames wrote:
>
> /builds/tomcat/ is redirected to /builds/jakarta-tomcat/ via an
> .htaccess file, so the bottom two refer to the same thing.
This actually exposes a new issue: invalid redirect fields.
GET /builds/tomcat/ HTTP/1.0
Host: jakarta.apache.org
returns
Location: /builds/jakarta-tomcat/index.html
The 'index.html' is one problem, new since 2.0.28. However,
the invalid absoluteURI issue is present even back in 2.0.28.
The relevant line in the .htaccess file is:
RedirectMatch /builds/tomcat/(.*) /builds/jakarta-tomcat/$1
Since there's no '[R]' flag, I'm not sure why this is forcing
an external redirect, either, rather than keeping it internal
and concealed from the client.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millenium hand and shrimp!"
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Greg Ames <gr...@remulak.net>.
"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
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Greg Ames" <gr...@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
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by Greg Ames <gr...@remulak.net>.
"William A. Rowe, Jr." wrote:
>
> > * 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?
ooops, I wasn't clear. We want extensions specified by AddLanguage to match,
and (since I code MultiviewsMatch Handlers) extentions specified by AddHandler.
I think that's all the extensions we want to match implicitly.
But looking at that backtrace, it looks like mod_negotiation might be thinking
that .1, .3, etc are interesting extensions, which is what 1.3 would do, and
therefore thinking that v3.1 from URI might match v3.1.1 it found by reading the
builds/jakarta-tomcat/release/ directory.
Greg
Re: mod_negotiation/dir subrequest problem [was: Tagging .31 soon]
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Greg Ames" <gr...@remulak.net>
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