httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: documentation/586: Clarity on <Location> usage (fwd)
Date Sat, 16 Aug 1997 22:15:38 GMT
Ok here's more docs.  Someone feel free to merge it in with the real docs.

Everything that is syntactically allowed in <Directory> is also allowed in
<Location> (except a sub-<Files> section, but the code doesn't test for
that, Lars has an open bug report on that).  Semantically however some
things, and the most notable is AllowOverrides, make no sense in
<Location>.  The same for <Files> -- syntactically everything is fine, but
semantically some things are different. 

The order of merging is:

<Directory> and .htaccess done simultaneously (.htaccess overrides <Dir>)
<Files> and <FilesMatch> done simultaneously
<Location> and <LocationMatch> done simultaneously

Each group is processed in the order that they appear in the configuration
files.  Note that using access.conf and srm.conf confuses things.  Combining
those with virtual hosts is even more confusing.  Note that a virtual host's
directives are processed AFTER all of the main host's directives (this is true
as of 1.2.2 and 1.3a2, prior to that it was backwards/broken).

Modifying .htaccess parsing during Location doesn't do anything because
.htaccess parsing has already occured.

The general guidelines are:

    If you are attempting to match objects at the filesystem level then
    you must use <Directory> and/or <Files>.

    If you are attempting to match objects at the URL level then you must
    use <Location>

a notable exception is:

    proxy control is done via <Directory>.  This is a legacy mistake because
    the proxy existed prior to <Location>.  A future version of the config
    language should probably switch this to <Location>.

Another note:

    There is actually a <Location>/<LocationMatch> sequence performed
    just before the name translation phase (where Aliases and DocumentRoots
    are used to map URLs to filenames).  The results of this sequence
    are completely thrown away after the translation has completed.

I think I did tweak the documentation for this ... but maybe I just planned
on tweaking but never got around to it.

The user's example below looks like it is supposed to be a <Directory>.


On Sat, 16 Aug 1997, Marc Slemko wrote: 

> This is related to something Dean said the other day.  Is currently
> in feedback state...
> Dean, you probably understand this best?
> ---------- Forwarded message ----------
> Date: Thu, 15 May 1997 14:00:02 -0700 (PDT)
> From: Daniel Rinehart <>
> To:
> Cc:
> Subject: documentation/586: Clarity on <Location> usage
> >Number:         586
> >Category:       documentation
> >Synopsis:       Clarity on <Location> usage
> >Confidential:   no
> >Severity:       non-critical
> >Priority:       medium
> >Responsible:    apache (Apache HTTP Project)
> >State:          open
> >Class:          doc-bug
> >Submitter-Id:   apache
> >Arrival-Date:   Thu May 15 14:00:01 1997
> >Originator:
> >Organization:
> apache
> >Release:        1.2b10
> >Environment:
> SunOS 4.1.4
> gcc version
> >Description:
> The current documentation for <Location> states:
> 	"It is comparable to the <Directory> directive"
> In the "Context:" section for commands location is never listed, but directory is.
> However, when trying to use the Options and AllowOverride directives in this sense:
> 	<Location /home/*>
> 	Options None
> 	AllowOverride None
> 	</Location>
> The results do not match the behavior indicated.
> >How-To-Repeat:
> >Fix:
> Better documentation of what directives <Location> can us
> >Audit-Trail:
> >Unformatted:

View raw message