nginx location详解(三)

location官方文档：http://nginx.org/en/docs/http/ngx_http_core_module.html#location

Syntax:    location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }
Default:     —
Context:    server, location

 

这个配置的设置依赖于请求的URL。

对规范化的URL进行匹配,文本解码后使用"%xx"的格式进行编码,解析由.和..组成的相对路径,并且可能压缩两个或2个以上的斜杠到单一的斜杠。

 location 可以被定义为一个前缀字符串,或者正则表达式.正则表达式使用~*(不区分大小写) 或 ~(区分大小写)被指定.

去查找location,匹配给到的请求.

nginx首先去检查使用prefix strings(prefix location)定义的locations. </images/ 这种的属于prefix string>

接着长的prefix strings被匹配记忆.

接下来 正则表达式被检测,在配置文件中的顺序去匹配

当搜索到第一个被匹配的正则表达式,将停止搜索,并且相应的配置项被应用

如果没有正则表达式被匹配到,更早的被查找到的prefix location被使用.

location 块是可以嵌套的,除了一下例外的情况:

　　不区分大小写的操作系统像 Mac Os x 和cygwin,忽略了与prfix strings的匹配.可是比较限于1字节的语言环境(comparison is limited to one-byte locales)<翻译不是很准确>
　　正则表达式可以包含捕获,稍后用于其他指令
　　如果最长前缀匹配位置有"^~"修饰符那么不进行正则匹配.
　　同样,使用"="修饰符,有可能定义一个URL和位置的精确匹配,如果精确匹配被发现,那么匹配结束.例如:如果"/"请求经常发生,定义了一个"location = /" 将加速这些请求的处理.在第一比较后搜索停止.这样的位置显然不能包含嵌套的位置.
　　在版本从0.7.1 到 0.8.41, 如果一个请求匹配到前缀位置 除了"=" 和"^~" 修饰符,搜索也终止和不进行正则匹配

让我们举个栗子:
location = / {
[ configuration A ]
}

location / {
[ configuration B ]
}

location /documents/ {
[ configuration C ]
}

location ^~ /images/ {
[ configuration D ]
}

location ~* \.(gif|jpg|jpeg)$ {
[ configuration E ]
}

"/" 请求会匹配配置文件A,
"/index.html" 匹配配置文件B
"/documents/documents.html" 匹配 C
"/images/" 匹配 D
"/images/1.jpd" 匹配 E

"@"前缀自定义了个location字符串.这样的一个location不用于常规请求的处理,但是用于请求的重定向.他不能被嵌套,也不能包含嵌套location
如果一个location被定义为前缀字符串,结束符是个斜线"/",并且请求由proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, or memcached_pass他们中的一个来处理,那么进行特殊的处理.响应请求URI等于这个字符串,但是不包含最后的"/",代码301永久重定向将被返回给请求添加斜线的URL.如果这不是你所希望的,一个URL精确的匹配和location被这样定义:
location /user/ {
proxy_pass http://user.example.com;
}

location = /user {
proxy_pass http://login.example.com;
}