Historically on unix it was syntactic... would you rather control access in filepath space or uri space? It seemed pretty simple to grant <location /images> read access, versus the </path/to/vhost/htdocs/images> so that was an early preference still used by some admins.
With case-insensitive filesystems it became a real problem. Granting access by location is still simple (request the correct case pathname for the uri, or the case-sensitive grant-ACL will fail), but denying access became tricky. Trickier still because case-flexible filesystems are also usually flexible in other, non-intuitive ways, like the handling of a trailing period on an NTFS volume. So <location > cannot be safely used to deny file access under several OS's, including several case-insensitive unix examples such as hfs+, samba shares etc. As with most historical artifacts, history often wins the debate over 'correctness'. On Mon, Jun 10, 2013 at 9:31 AM, Eric Covener <cove...@gmail.com> wrote: > On Mon, Jun 10, 2013 at 10:03 AM, Reindl Harald <h.rei...@thelounge.net> > wrote: > > > > > > Am 10.06.2013 15:58, schrieb Eric Covener: > >>> <Directory "/"> > >>> Options -Indexes -ExecCGI -MultiViews +FollowSymLinks > >>> AllowOverride None > >>> Require all denied > >>> </Directory> > >>> > >>> does not mean i do not need the possibility to allow > >>> a specific Locations/Aliases outside this and the > >>> same for specific exceptions inside vhosts with <Directory> > >>> directives > >> > >> But none of that requires a Location that merges later, it's just more > >> brief than a subsequent Directory/Files > > > > define "requires" > > Necessary for the result. > > > thhere are millions of configs out there which are tested and > > often enough Directory/Files/Location are used in whatever > > combinations > > > if someone would change the order of this merging it would > > be a unpredicatable change - period > > > you can suggest such changes for Apache 2.5 or Apache 3.0 > > and even there only with a damned good reason - period > > This should be obvious, but none of it precludes discussion here - > exclamation point. >
