httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [BUG] <Location /dir> doesn't work as expected when there is a /dir in the DocumentRoot
Date Tue, 19 Mar 2002 12:00:42 GMT
On Mon, Mar 04, 2002 at 10:42:33AM -0800, Ian Holsman wrote:
> Sander Striker wrote:
> > Hi,
> > 
> > I've reproduced the problem reported by Vlad Skvortsov
> > locally and I'll describe it once more together with
> > some feedback I got.
> > 
> > From the config:
> >     DocumentRoot /htdocs
> > 
> >     <Location /repos>
> >         DAV svn
> >         SVNPath /htdocs/repos 
> >     </Location>
> > 
> > In the /htdocs path, there is a directory called repos.
> > The directory seems to win over the Location (badness!).

Yes. This is bad. A Location was explicitly configured. The directory should
not preempt a user's configuration.

However, the problem was never fully explained. In my testing, it got a 301,
which is debatably correct.

> > The OPTIONS request to http://example.com/repos will
> > indicate a non-dav-enabled resource.

As a side effect of the Location not working properly, mod_dav does not get
to handle the request, so the default handler deals with it, which certainly
means that the OPTIONS won't show a DAV-enabled resource :-)

> > On irc OtherBill stated that mod_dav chose not to override map_to_storage*,
> > but Location should still win over Dir.  His guess was that mod_davs OPTIONS
> > intercept could be borked.

Has nothing to do with mod_dav. The Location didn't "take", so *whatever*
was configured there isn't going to work.

In any case, the current directory/location walk code is amazingly
inconsistent. For example: let's say that we have the above Location
directive, and a directory named "repos" under the DocumentRoot.

OPTIONS /repos          -- returns a 301 redirect for /repos/
                           (generated by mod_dir)
OPTIONS /repos/         -- mod_dav returns the appropriate options
OPTIONS /repos/foo.html -- mod_dav returns the appropriate options

If the subdir is not there, then mod_dav gets the first one.

Hunh... I just added a User-Agent header to the request to trigger the
"redirect-carefully", so that mod_dir wouldn't do its work.

If the problem was simply sending a 301 back, then it could be argued that
is correct. The client "should" definitely be able to handle it. And
sometimes that trailing slash *is* desired (and note when the slash is
present, that it is handled appropriately by mod_dav and its backend
provider).

>...
> you need to implement a m-to-s hook for this.

The m-to-s hook is absolutely undocumented. How can a module author possibly
use the thing? The various location/directory/file walks *still* occur when
map_to_storage is present, so what is the point? What is it supposed to do?
How does it signal a walk should or should not occur? (heck, is it even
supposed to obviate a walk?) If it runs, what is it supposed to fill in?
Does that tell the system not to do a walk?

[ ap_process_request_internal appears to run walks even when map_to_storage
  is going to be used ]

>From my standpoint, m-to-s isn't an option right now. I can't see how it
relates to the normal processing...

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message