The following reply was made to PR documentation/586; it has been noted by GNATS.
From: Dean Gaudet <[EMAIL PROTECTED]> To: [email protected] 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 <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > >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: > > >
