新版翻译
location
location
syntax: location [=|~|~*|^~|@] /uri/ { ... }
语法: location [=|~|~*|^~|@] /uri/ { ... }
语法: location [=|~|~*|^~|@] /uri/ { ... }
default: no
默认: 否
默认: 否
context: server
上下文: server
上下文: server
This directive allows different configurations depending on the URI. It can be configured using both literal strings and regular expressions. To use regular expressions, you must use a prefix:
这个变量允许按照根据URI使用不同的配置.配置可以使用普通的字符串或者是正则表达式.使用正则表达式,必须使用一个前缀:
这个变量允许按照根据URI使用不同的配置.配置可以使用普通的字符串或者是正则表达式.使用正则表达式,必须使用一个前缀:
1. "~" for case sensitive matching
2. "~*" for case insensitive matching
1. "~" 用于区分大小写(大小写敏感)的匹配
2. "~*" 用于不区分大小写的匹配
2. "~*" for case insensitive matching
1. "~" 用于区分大小写(大小写敏感)的匹配
2. "~*" 用于不区分大小写的匹配
To determine which location directive matches a particular query, the literal strings are checked first. Literal strings match the beginning portion of the query - the most specific match will be used. Afterwards, regular expressions are checked in the order defined in the configuration file. The first regular expression to match the query will stop the search. If no regular expression matches are found, the result from the literal string search is used.
在决定哪个location变量来匹配一个特定的查询时,普通字符串会先检查.普通字符串查找查询的开头做匹配 -- 将会使用最明确的那个匹配(我的理解是:使用匹配得最完整的那个字符串的配置).然后正则表达式按照配置文件里面的顺序来匹配.第一个匹配查询的正则表达式会停止剩下的查找.如果没有匹配的正则表达式,就会使用普通字符串的查找结果.
在决定哪个location变量来匹配一个特定的查询时,普通字符串会先检查.普通字符串查找查询的开头做匹配 -- 将会使用最明确的那个匹配(我的理解是:使用匹配得最完整的那个字符串的配置).然后正则表达式按照配置文件里面的顺序来匹配.第一个匹配查询的正则表达式会停止剩下的查找.如果没有匹配的正则表达式,就会使用普通字符串的查找结果.
For caseless operation systems, like Mac OS X and Cygwin, liternal string matching will be done in case insensitive way (0.7.7). However, comparision is limited to single-byte locale's only.
对于小部分系统,如Mac OS X 和Cygwin,普通字符串会以不区分大小写的情况来做匹配(0.7.7).但是,这种区别仅限于单字节 locale的 情况.
对于小部分系统,如Mac OS X 和Cygwin,普通字符串会以不区分大小写的情况来做匹配(0.7.7).但是,这种区别仅限于单字节 locale的 情况.
Regular expression may contain captures (0.7.40), which can be used in other directives.
正则表达式可以包含capture(0.7.40),capture可以用在其他的指令中.
正则表达式可以包含capture(0.7.40),capture可以用在其他的指令中.
It is possible to disable regular expression checks after liternal string matching by using "^~" prefix. If most specific match literal location have this prefix - regular expressions aren't checked.
"^~" 这个前缀的作用:在常规的字符串匹配检查之后,不做正则表达式的检查---即如果最明确的那个字符串匹配的location配置中有此前缀,那么不会做正则表达式的检查.
"^~" 这个前缀的作用:在常规的字符串匹配检查之后,不做正则表达式的检查---即如果最明确的那个字符串匹配的location配置中有此前缀,那么不会做正则表达式的检查.
By using "=" prefix on may define exact match between URI and location. On match search stops immediately as further search has no sense. E.g. if the request "/" occurs frequently, using "location = /" will speed up processing of this request a bit as search will stop after first comparison.
使用 "=" 前缀可以做URI和location的精确匹配.匹配之后查询就会停止.例如,如果 "/" 这个请求常出现,使用 "location = /" 将会提高一点处理这个请求的速度.
使用 "=" 前缀可以做URI和location的精确匹配.匹配之后查询就会停止.例如,如果 "/" 这个请求常出现,使用 "location = /" 将会提高一点处理这个请求的速度.
On exact match with literal location without "=" or "^~" prefixes search is also immediately terminated.
(如何理解翻译?)
(如何理解翻译?)
To summarize, the order in which directives are checked is as follows:
总的来说,以如下的顺序来检查指令:
总的来说,以如下的顺序来检查指令:
1. Directives with the "=" prefix that match the query exactly. If found, searching stops.
1. 有 "=" 前缀的指令对"查询"做精确的匹配,如果找到了,查找停止.
2. All remaining directives with conventional strings. If this match used the "^~" prefix, searching stops.
2. 指令为常规字符串.如果匹配中使用了 "^~" ,查找停止.
3. Regular expressions, in the order they are defined in the configuration file.
3. 指令为正则表达式.按照配置文件里面的顺序查找.
4. If #3 yielded a match, that result is used. Otherwise, the match from #2 is used.
4. 如果#3找到了,那么就用3的.否则,就用#2的.
It is important to know that nginx does the comparison against decoded URIs. For example, if you wish to match "/images/%20/test", then you must use "/images/ /test" to determine the location.
提醒:nginx会对编码过的URI做比较.例如,如果你想要匹配"/images/%20/test" , 你必须使用 "/images/ /test" 来定义这个location
提醒:nginx会对编码过的URI做比较.例如,如果你想要匹配"/images/%20/test" , 你必须使用 "/images/ /test" 来定义这个location
Example:
location = / {
# matches the query / only.
[ configuration A ]
}
location / {
# matches any query, since all queries begin with /, but regular
# expressions and any longer conventional blocks will be
# matched first.
[ configuration B ]
}
location ^~ /images/ {
# matches any query beginning with /images/ and halts searching,
# so regular expressions will not be checked.
[ configuration C ]
}
location ~* \.(gif|jpg|jpeg)$ {
# matches any request ending in gif, jpg, or jpeg. However, all
# requests to the /images/ directory will be handled by
# Configuration C.
[ configuration D ]
}
# matches the query / only.
[ configuration A ]
}
location / {
# matches any query, since all queries begin with /, but regular
# expressions and any longer conventional blocks will be
# matched first.
[ configuration B ]
}
location ^~ /images/ {
# matches any query beginning with /images/ and halts searching,
# so regular expressions will not be checked.
[ configuration C ]
}
location ~* \.(gif|jpg|jpeg)$ {
# matches any request ending in gif, jpg, or jpeg. However, all
# requests to the /images/ directory will be handled by
# Configuration C.
[ configuration D ]
}
Example requests:
* / -> configuration A
* /documents/document.html -> configuration B
* /images/1.gif -> configuration C
* /documents/1.jpg -> configuration D
* /documents/document.html -> configuration B
* /images/1.gif -> configuration C
* /documents/1.jpg -> configuration D
Note that you could define these 4 configurations in any order and the results would remain the same. While nested locations are allowed by the configuration file parser, their use is discouraged and may produce unexpected results.
注意:上面的4段在文件中顺序可以是任意的,出来的效果都一样.虽然嵌套的location 指令是允许的,但不建议!会引起非预期的结果.
注意:上面的4段在文件中顺序可以是任意的,出来的效果都一样.虽然嵌套的location 指令是允许的,但不建议!会引起非预期的结果.
The prefix "@" specifies a named location. Such locations are not used during normal processing of requests, they are intended only to process internally redirected requests (see error_page, try_files).
"@" 前缀指定的是一个命名的location.这样的location在一般的请求处理中是不适用的, 仅仅设计来处理内部的重定向请求(查看error_page, try_files).
"@" 前缀指定的是一个命名的location.这样的location在一般的请求处理中是不适用的, 仅仅设计来处理内部的重定向请求(查看error_page, try_files).
本文转自yahoon 51CTO博客，原文链接：http://blog.51cto.com/yahoon/285484，如需转载请自行联系原作者
