* Joshua Slive <[EMAIL PROTECTED]> wrote: > > On Wed, 4 Feb 2004, [ISO-8859-15] André Malo wrote: > > > * [EMAIL PROTECTED] wrote: > > > > > If there are sites out there that ignore the piece about the content > > > living outside the filesystem, my previous patch which requires no new > > > configuration might create problems. This version adds an > > > OutsideFilesystem directive, only valid in <Location>, to eliminate the > > > possibility for unpleasant surprises when upgrading httpd. It causes > > > the directory walk to be skipped if set. btw, I'm thinking of this as a > > > 2.1 thing which wouldn't be backported. > > > > (without closer looking at the code) > > I'd suggest rather > > > > <Location [virtual] /uri-path> > > </Location> > > > > where the virtual keyword defines that the location is independent from > > filesystem. > > Perhaps I'm misunderstanding the issue, but neither of these make sense to > me. It is not really the behavior of the <Location> block that is > changing. <Location> always acts outside the filesystem. What is > changing is that a certain directive inside a <Location> block should be > applied differently. So shouldn't this just be > > SetVirtualHandler server-status > or > SetHandler virtual server-status
The aim is to skip directory and files container merging. When using Sethandler I'd see an inconsistency that it cannot apply e.g. to AddHandler directives [not in core] and should be applied to ForceType as well. <Location virtual> is complete core and would be one central interface. I'd guess, it's finally just a naming issue, isn't it? ("virtual" may be not intutitive enough anyway) nd