From: dgaudet listen(2)
system call.
The <Location> directive provides for access control by
-URL. It is comparable to the <Directory> directive, and
-should be matched with a </Location> directive. Directives that
-apply to the URL given should be listed
-within. <Location>
sections are processed in the
+starts a subsection which is terminated with a </Location>
+directive. <Location>
sections are processed in the
order they appear in the configuration file, after the
<Directory> sections and .htaccess
files are
-read.
Note that, due to the way HTTP functions, URL prefix
-should, save for proxy requests, be of the form /path/
,
-and should not include the http://servername
. It doesn't
-necessarily have to protect a directory (it can be an individual
-file, or a number of files), and can include wild-cards. In a wild-card
-string, `?' matches any single character, and `*' matches any
-sequences of characters.
+
Note that URLs do not have to line up with the filesystem at all, +it should be emphasized that <Location> operates completely outside +the filesystem. + +
For all origin (non-proxy) requests, the URL to be matched is
+of the form /path/
, and you should not include any
+http://servername
prefix. For proxy requests, the URL
+to be matched is of the form scheme://servername/path
,
+and you must include the prefix.
+
+
The URL may use wildcards In a wild-card string, `?' matches any +single character, and `*' matches any sequences of characters.
Apache 1.2 and above:
Extended regular expressions can also be used, with the addition of
-the
-~
character. For example:
~
character.
+
+For example:
<Location ~ "/(extra|special)/data">
would match URLs that contained the substring "/extra/data" or -"/special/data". However, in Apache 1.3 and above, use of <LocationMatch> is preferred.
+"/special/data". In Apache 1.3 and above, a new directive +<LocationMatch> exists which +behaves identical to the regex version of +<Location>
.
The Apache 1.3 and above note about / (slash): The slash character has special
+meaning depending on where in a URL it appears. People may be used
+to its behaviour in the filesystem where multiple adjacent slashes are
+frequently collapsed to a single slash (i.e.
See also: How Directory,
Location and Files sections work for an explanation of how these
Location
functionality is especially useful when
combined with the
+
/home///foo
+is the same as /home/foo
). In URL-space this is not
+necessarily true. The <LocationMatch>
directive
+and the regex version of <Location>
require you
+to explicitly specify multiple slashes if that is your intention.
+For example, <LocationMatch ^/abc>
would match the
+request URL /abc
but not the request URL //abc
.
+The (non-regex) <Location>
directive behaves
+similarly when used for proxy requests. But when (non-regex)
+<Location>
is used for non-proxy requests it will
+implicitly match multiple slashes with a single slash. For example,
+if you specify <Location /abc/def>
and the request
+is to /abc//def
then it will match.
+