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/
