Директива <Location> ограничивает область применения вложенных директив URL-адресом. Он похож на
<Directory>
директиву и начинает подраздел, который заканчивается директивой
</Location> . <Location> секции обрабатываются в порядке их появления в конфигурационном файле, после чтения <Directory> секций и
файлов и после секций. .htaccess <Files>
<Location> разделы работают полностью вне файловой системы. Это имеет несколько последствий. Самое главное, <Location>
директивы не должны использоваться для управления доступом к расположениям файловой системы. Поскольку несколько разных URL-адресов могут сопоставляться с одним и тем же расположением в файловой системе, такой контроль доступа можно обойти.
Прилагаемые директивы будут применяться к запросу, если компонент пути URL-адреса соответствует любому из следующих критериев:
- Указанное местоположение точно соответствует компоненту пути URL-адреса.
- Указанное местоположение, оканчивающееся косой чертой, является префиксом компонента пути URL-адреса (рассматривается как корень контекста).
- Указанное местоположение с добавлением завершающей косой черты является префиксом компонента пути URL-адреса (также рассматривается как корень контекста).
В приведенном ниже примере, где косая черта в конце не используется, к запросам к /private1, /private1/ и /private1/file.txt будут применены вложенные директивы, а к /private1other — нет.
<Location "/private1">
# ...
</Location>
В приведенном ниже примере, где используется завершающая косая черта, к запросам к /private2/ и /private2/file.txt будут применены вложенные директивы, а к /private2 и /private2other — нет.
<Location "/private2/">
# ...
</Location>
Когда использовать <Location>
Используйте <Location> для применения директив к содержимому, находящемуся вне файловой системы. Для содержимого, находящегося в файловой системе, используйте <Directory> и <Files> . Исключением является
<Location "/"> , который представляет собой простой способ применить конфигурацию ко всему серверу.
Для всех исходных (не прокси) запросов сопоставляемый URL-адрес представляет собой URL-путь в форме /path/ . Нельзя включать схему, имя хоста, порт или строку запроса. Для прокси-запросов сопоставляемый URL-адрес имеет форму
scheme://servername/path , и вы должны включать префикс.
URL-адрес может использовать подстановочные знаки. В строке с подстановочными знаками ? соответствует любому одиночному символу и * соответствует любой последовательности символов. Ни один подстановочный знак не соответствует / в URL-пути.
Также можно использовать регулярные выражения
с добавлением символа ~
. Например:
<Location ~ "/(extra|special)/data">
#...
</Location>
будет соответствовать URL-адресам, содержащим подстроку /extra/data
или /special/data . Директива <LocationMatch> ведет себя так же, как версия регулярного выражения <Location> , и предпочтительнее по той простой причине, что ~ ее трудно отличить
- во многих шрифтах.
Функциональность <Location>
особенно полезна в сочетании с директивой
SetHandler
. Например, чтобы включить запросы статуса, но разрешить их только из браузеров в example.com , вы можете использовать:
<Location "/status">
SetHandler server-status
Require host example.com
</Location>
Примечание о / (косая черта)
Символ косой черты имеет особое значение в зависимости от того, где в URL-адресе он появляется. Люди могут привыкнуть к его поведению в файловой системе, где несколько смежных косых черт часто сворачиваются в одну косую черту ( т.е. /home///foo это то же самое
, что и /home/foo ). В URL-пространстве это не обязательно верно. Директива <LocationMatch>
и версия регулярного выражения <Location> требуют, чтобы вы явно указали несколько косых черт, если это ваше намерение.
Например, <LocationMatch "^/abc"> будет соответствовать URL-адресу запроса /abc , но не URL-адресу запроса
//abc . Директива (non-regex) <Location> ведет себя аналогично при использовании для прокси-запросов. Но когда (non-regex) <Location> используется для запросов без прокси, он будет неявно сопоставлять несколько косых черт с одной косой чертой. Например, если вы укажете <Location "/abc/def"> и запрос будет, /abc//def то он будет соответствовать.
Смотрите также
- Как работают разделы <Directory>, <Location> и <Files> для объяснения того, как эти разные разделы объединяются при получении запроса.
-
LocationMatch
