> -----Original Message-----
> From: Greg Stein [mailto:[EMAIL PROTECTED]]
> > I don't see any config directives that "belong" in <Location />.
> > Please be more specific before you do anything.
>
> Options Indexes
> AllowOverride None
> Order allow,deny
> Allow from all
> AddHandler type-map var
> DirectoryIndex index.html index.html.var
>
> The only thing that is filesystem specific are:
>
> Options FollowSymLinks
No. I'm not saying they belong in <Directory> because they are
"filesysystem specific". They belong in <Directory> because they are being
applied to resources living in the filesystem.
There are lots of issues here. In general, <Location /> is "safe" in all
contexts because there is no way to get around it. But it still will not
work to throw all this stuff into <Location /> for at least two reasons:
1. (Important) As OtherBill has been trying to point out, <Location> is
applied after <Directory>. Therefore,
if you put these things in <Location />, lots of things in <Directory> will
fail to work. People won't understand why
this doesn't deny access to anything:
<Location />
Order allow,deny
allow from all
</Location>
<Directory /path/to/really/secret/stuff>
deny from all
</Directory>
2. (Less important) As a pedagogical issue, we don't want to encourage its
use in preference to <Directory>. When resources are not in the filesystem,
<Location> is the way to go. But when resources are in the filesystem,
<Directory> should be used whenever possible.
I never argued that <Location> shouldn't be used. It just shouldn't be used
in circumstances where <Directory> would suffice because it can lead to
subtle security problems.
The fact remains, there is really no way to set defaults for things so that
they will apply for all resources, and yet can still be overridden by
<Directory> sections. I don't know any way around that, other than to make
sure the compile-time defaults are sensible.
Joshua.
