Re: documentation/586: Clarity on usage (fwd)

[Dean Gaudet <dg...@arctic.org>]

The following reply was made to PR documentation/586; it has been noted by GNATS.

From: Dean Gaudet <dg...@arctic.org>
To: new-httpd@apache.org
Subject: Re: documentation/586: Clarity on <Location> usage (fwd)
Date: Sat, 16 Aug 1997 15:15:38 -0700 (PDT)

 
 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>)
 <DirectoryMatch>
 <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>.
 
 Dean
 
 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 <da...@ccs.neu.edu>
 > To: apache-bugdb@apache.org
 > Cc: apache-bugdb@apache.org
 > 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:     danielr@ccs.neu.edu
 > >Organization:
 > apache
 > >Release:        1.2b10
 > >Environment:
 > SunOS 4.1.4
 > gcc version 2.7.2.1
 > >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:
 > 
 > 
 >