<Location> 指令
描述: | 仅将随附的指令应用于匹配的URL |
---|---|
句法: | <Location URL-path|URL>...</Location> |
内容: | 服务器配置,虚拟主机 |
状态: | 核心 |
模组: | 核心 |
该<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>
将匹配包含子字符串/extra/data
或的URL /special/data
。该指令的<LocationMatch>
行为与的regex版本相同<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
。<Location>
当用于代理请求时,(非正则表达式)指令的行为类似。但是,当(非正则表达式)<Location>
用于非代理请求时,它将隐式地将多个斜杠与单个斜杠匹配。例如,如果您指定<Location "/abc/def">
且请求为,/abc//def
则它将匹配。
参见
- <Directory>,<Location>和<Files>部分的工作方式,以解释接收请求时如何组合这些不同的部分。
LocationMatch