I just want to add a couple notes here on what I see as user-expectations.
> > The problem is that you want to add layers of additional directives, which > > would change the behavior of <Directory > or <Location >, > > only <Location >, in a way that IMO is consistent with the existing > documentation, but not the existing code of course. [...] > A complication to treating <Location > as if it's outside the filesystem > is the doc that states <Location /> is a quick way to apply a config to > the whole server. It will indeed do that today, unfortunately. I > believe another quick way to get the same result is to put your config > directives outside of any container. If that's true, I would prefer to > see that doc for <Location /> removed. If the change to the behavior of > <Location > is configurable, this is not an issue. If it's not > configurable, then we probably should treat <Location /> as if it's in > the filesystem - a special case for backwards compatibility. I wrote the particular doc you quoted earlier, and I meant it more as a recommendation (for security reasons) than a documentation of how apache works. The true description of how apache is supposed to function is here: http://httpd.apache.org/docs-2.0/sections.html (But it is a little vauge, because my knowledge of the internals of configuration merging was not sufficient to clarify it the last time I went through.) Many people do, in fact, use <Location> for filesystem-related things. See the examples in the mod_dav docs for one: http://httpd.apache.org/docs-2.0/mod/mod_dav.html Although I don't think this is esthetically correct, it is not particularly dangerous. Using <Location> to provide *extra* access is okay, because if you circumvent the <Location> using filesystem tricks, you just lose the access. Using <Location> to *restrict* access is not safe, because the restrictions may be circumvented. The other important thing to note is that <Location> is often used for a reason that is particular to apache configuration merging: those sections are evaluated last. That means that <Location /> Order deny,allow Deny from all Allow from local.net </Location> has a very different effect than the same directives placed in <Directory /> because it will be evaluated after all <Directory> and <Files> sections which could potentially override directives. I'm not saying that this is a strictly correct use of <Location>, but it is very useful and there is no other easy way to accomplish this "apply this directive after everything else" effect. I do, however, agree that doing a directory-walk on virtual resources is not nice. But my opinion is that "virtualness" is a property of the resource, and hence should be designated when selecting the resource. That is why I suggested changing SetHandler rather than <Location>. Joshua.
