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;}