* 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
