| Syntax: | location [ location |
|---|---|
| Default: | — |
| Context: | server, location |
Sets configuration depending on a request URI.
依靠請求的URI設置配置
The matching is performed against a normalized URI,after decoding the text encoded in the “%XX” form,resolving references to relative path components “.”and “..”, and possiblecompression
of two or more adjacent slashes into a single slash.
匹配是同通常的URI進行，文本被編碼成"%XX"格式後，就參考相關的路徑組件去解決。對於"."和 ".."，兩個或者多個相鄰的"/"有可能會壓縮成單個"/" 。
A location can either be defined by a prefix string, or by a regular expression.Regular expressions are specified with the preceding“~*” modifier (for case-insensitive matching), or the“~” modifier (for case-sensitive matching).To
find location matching a given request, nginx first checks locations defined using the prefix strings (prefix locations).Among them, the location with the longest matchingprefix is selected and remembered.Then regular expressions are checked, in the order
of their appearancein the configuration file.The search of regular expressions terminates on the first match,and the corresponding configuration is used.If no match with a regular expression is found then theconfiguration of the prefix location remembered
earlier is used.
location既能用前綴字符串定義也可以用正則表達式定義。正則表達式以"~*"修飾符開頭（大小寫敏感的匹配），或者以"~" 修飾符開頭（大小寫不敏感的匹配）。找到一個location去匹配一個指定的請求，nginx首先去匹配用前綴字符串定義的location（前綴locations）。在這些前綴location之間，最長匹配前綴的將會被選擇並記住。然後，檢查正則表達式定義的location，匹配順序按照正則表達式location在配置文件中出現的順序進行匹配。正則表達式的匹配在第一個匹配上的location的地方結束，然後這個location的配置會被使用，如果沒有找到匹配到的正則表達式，就使用先前在前綴location中匹配到的location。
location blocks can be nested, with some exceptions mentioned below.
location block可以被內嵌到除下面提到的指令中。
For case-insensitive operating systems such as Mac OS X and Cygwin,matching with prefix strings ignores a case (0.7.7).However, comparison is limited to one-byte locales.
對於像Mac OS X 和 Cygwin這樣的大小寫敏感的操作系統，匹配前綴字符串的時候要忽略大小寫。然而，壓縮僅限於在一個字節的地方。
Regular expressions can contain captures (0.7.40) that can later be used in other directives.
If the longest matching prefix location has the “^~” modifier then regular expressions are not checked.
如果最長匹配的前綴location是帶有“^~”修飾符，就不用去匹配正則表達式了。
Also, using the “=” modifier it is possible to define an exact match of URI and location.If an exact match is found, the search terminates.For example, if a “/” request happens frequently,defining “location = /” will
speed up the processing of these requests, as search terminates right after the first comparison.Such a location cannot obviously contain nested locations.
同樣，使用“=”修飾符主要可能是去定義一個精確的URI以及location。如果一個精確的匹配被找到，搜索終止。比如，如果一個“/”的請求出現的很頻繁，那麼定義一個“location = /”將會加速這些請求的執行。因爲在第一個比較的時候就會終止搜索了。此類location不能明顯的包含嵌入的location。
In versions from 0.7.1 to 0.8.41, if a request matched the prefix location without the “=” and “^~”modifiers, the search also terminated and regular expressions werenot checked.
Let’s illustrate the above by an example:
location = / {
[ configuration A ]
}
location / {
[ configuration B ]
}
location /documents/ {
[ configuration C ]
}
location ^~ /images/ {
[ configuration D ]
}
location ~* \.(gif|jpg|jpeg)$ {
[ configuration E ]
}
The “/” request will match configuration A,the “/index.html” request will match configuration B,the “/documents/document.html” request will matchconfiguration C,the “/images/1.gif” request will match configuration
D, andthe “/documents/1.jpg” request will match configuration E.
The “@” prefix defines a named location.Such a location is not used for a regular request processing, but instead used for request redirection.They cannot be nested, and cannot contain nested locations.
If a location is defined by a prefix string that ends with the slash character,and requests are processed by one ofproxy_pass,fastcgi_pass,uwsgi_pass,scgi_pass, ormemcached_pass,then the special processing is performed.In response to a request with URI equal to this string,but without the trailing slash,a permanent redirect with the code 301 will be returned to the requested URI with the slash appended.If this is not desired, an exact match of the URI and location could bedefined like this:
location /user/ {
proxy_pass http://user.example.com;
}
location = /user {
proxy_pass http://login.example.com;
}