當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

关于一些对location认识的误区(转)

發(fā)布時間：2024/9/5 编程问答 28 豆豆

生活随笔收集整理的這篇文章主要介紹了关于一些对location认识的误区(转) 小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

轉(zhuǎn)自：http://www.cnblogs.com/lidabo/p/4169396.html

1、?location?的匹配順序是“先匹配正則，再匹配普通”。

矯正：?location?的匹配順序其實是“先匹配普通，再匹配正則”。我這么說，大家一定會反駁我，因為按“先匹配普通，再匹配正則”解釋不了大家平時習(xí)慣的按“先匹配正則，再匹配普通”的實踐經(jīng)驗。這里我只能暫時解釋下，造成這種誤解的原因是：正則匹配會覆蓋普通匹配（實際的規(guī)則，比這復(fù)雜，后面會詳細(xì)解釋）。

2、?location?的執(zhí)行邏輯跟?location?的編輯順序無關(guān)。

矯正：這句話不全對，“普通?location?”的匹配規(guī)則是“最大前綴”，因此“普通?location?”的確與?location?編輯順序無關(guān)；但是“正則?location?”的匹配規(guī)則是“順序匹配，且只要匹配到第一個就停止后面的匹配”；“普通location?”與“正則?location?”之間的匹配順序是？先匹配普通?location?，再“考慮”匹配正則?location?。注意這里的“考慮”是“可能”的意思，也就是說匹配完“普通?location?”后，有的時候需要繼續(xù)匹配“正則?location?”，有的時候則不需要繼續(xù)匹配“正則?location?”。兩種情況下，不需要繼續(xù)匹配正則?location?：（?1?）當(dāng)普通?location?前面指定了“?^~?”，特別告訴?Nginx?本條普通?location?一旦匹配上，則不需要繼續(xù)正則匹配；（?2?）當(dāng)普通location?恰好嚴(yán)格匹配上，不是最大前綴匹配，則不再繼續(xù)匹配正則。

總結(jié)一句話： ?“正則 location 匹配讓步普通 location 的嚴(yán)格精確匹配結(jié)果；但覆蓋普通 location 的最大前綴匹配結(jié)果”

官方文檔解釋

REFER:??http://wiki.nginx.org/NginxHttpCoreModule#location

location

syntax:?location [=|~|~*|^~|@] /uri/ { … }

default:?no

context:?server

This directive allows different configurations depending on the URI.

（譯者注：1?、different configurations depending on the URI?說的就是語法格式：location [=|~|~*|^~|@] /uri/ { … }?，依據(jù)不同的前綴“=?”，“^~?”，“~?”，“~*?”和不帶任何前綴的（因為[A]?表示可選，可以不要的），表達(dá)不同的含義,?簡單的說盡管location?的/uri/?配置一樣，但前綴不一樣，表達(dá)的是不同的指令含義。2?、查詢字符串不在URI范圍內(nèi)。例如：/films.htm?fid=123?的URI?是/films.htm?。）

It can be configured using both literal strings and regular expressions. To use regular expressions, you must use a prefix:

“~” for case sensitive matching

“~*” for case insensitive matching

譯文：上文講到location /uri/?可通過使用不同的前綴，表達(dá)不同的含義。對這些不同前綴，分下類，就2?大類：正則location?，英文說法是location using regular expressions?和普通location?，英文說法是location using literal strings?。那么其中“~?”和“~*?”前綴表示正則location?，“~?”區(qū)分大小寫，“~*?”不區(qū)分大小寫；其他前綴（包括：“=”，“^~?”和“@?”）和無任何前綴的都屬于普通location?。

To determine which?location?directive matches a particular query, the literal strings are checked first.

譯文：對于一個特定的?HTTP?請求（?a particular query?），?nginx?應(yīng)該匹配哪個?location?塊的指令呢（注意：我們在?nginx.conf?配置文件里面一般會定義多個?location?的）？匹配?規(guī)則是：先匹配普通location?（再匹配正則表達(dá)式）。注意：官方文檔這句話就明確說了，先普通location?，而不是有些同學(xué)的誤區(qū)“先匹配正則location?”。

Literal strings match the beginning portion of the query – the most specific match will be used.

前面說了“普通location?”與“正則location?”之間的匹配規(guī)則是：先匹配普通location?，再匹配正則location?。那么，“普通location?”內(nèi)部（普通location?與普通location?）是如何匹配的呢？簡單的說：最大前綴匹配。原文：1、match the beginning portion of the query?（說的是匹配URI?的前綴部分beginning portion?）；?2?、the most specific match will be used?（因為location?不是“嚴(yán)格匹配”，而是“前綴匹配”，就會產(chǎn)生一個HTTP?請求，可以“前綴匹配”到多個普通location?，例如：location /prefix/mid/ {}?和location /prefix/ {}?，對于HTTP?請求/prefix/mid/t.html?，前綴匹配的話兩個location?都滿足，選哪個？原則是：the most specific match?，于是選的是location /prefix/mid/ {}?）。

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.

這段話說了兩層意思，第一層是：“Afterwards, regular expressions are checked?”,?意思是普通location?先匹配，而且選擇了最大前綴匹配后，不能就停止后面的匹配，最大前綴匹配只是一個臨時的結(jié)果，nginx?還需要繼續(xù)檢查正則location?（但至于最終才能普通location?的最大前綴匹配，還是正則location?的匹配，截止當(dāng)前的內(nèi)容還沒講，但后面會講）。第二層是“regular expressions are checked in the order defined in the configuration file. The first regular expression to match the query will stop the search.?”，意思是說“正則location?”與“正則location”內(nèi)部的匹配規(guī)則是：按照正則location?在配置文件中的物理順序（編輯順序）匹配的（這句話就說明location?并不是一定跟順序無關(guān)，只是普通location?與順序無關(guān)，正則location?還是與順序有關(guān)的），并且只要匹配到一條正則location?，就不再考慮后面的（這與“普通location?”與“正則location?”之間的規(guī)則不一樣，“普通location?”與“正則location?”之間的規(guī)則是：選擇出“普通location?”的最大前綴匹配結(jié)果后，還需要繼續(xù)搜索正則location?）。

If no regular expression matches are found, the result from the literal string search is used.

這句話回答了“普通location?”的最大前綴匹配結(jié)果與繼續(xù)搜索的“正則location?”匹配結(jié)果的決策關(guān)系。如果繼續(xù)搜索的“正則location?”也有匹配上的，那么“正則location?”覆蓋?“普通location?”的最大前綴匹配（因為有這個覆蓋關(guān)系，所以造成有些同學(xué)以為正則location?先于普通location?執(zhí)行的錯誤理解）；但是如果“正則location?”沒有能匹配上，那么就用“普通location?”的最大前綴匹配結(jié)果。

For case insensitive operating systems, like Mac OS X or Windows with Cygwin, literal string matching is done in a case insensitive way (0.7.7). However, comparison is limited to single-byte locale’s only.

Regular expression may contain captures (0.7.40), which can then be used in other directives.

It is possible to disable regular expression checks after literal string matching by using “^~” prefix.If the most specific match literal location has this prefix: regular expressions aren’t checked.

通常的規(guī)則是，匹配完了“普通location?”指令，還需要繼續(xù)匹配“正則location?”，但是你也可以告訴Nginx?：匹配到了“普通location?”后，不再需要繼續(xù)匹配“正則location?”了，要做到這一點只要在“普通location?”前面加上“^~?”符號（^?表示“非”，~?表示“正則”，字符意思是：不要繼續(xù)匹配正則）。

By using the “=” prefix we define the?exact?match between request URI and location. When matched search stops immediately.?E.g., if the request “/” occurs frequently, using “l(fā)ocation = /” will speed up processing of this request a bit as search will stop after first comparison.

除了上文的“^~?”可以阻止繼續(xù)搜索正則location?外，你還可以加“=?”。那么如果“^~?”和“=?”都能阻止繼續(xù)搜索正則location?的話，那它們之間有什么區(qū)別呢？區(qū)別很簡單，共同點是它們都能阻止繼續(xù)搜索正則location?，不同點是“^~?”依然遵守“最大前綴”匹配規(guī)則，然而“=?”不是“最大前綴”，而是必須是嚴(yán)格匹配（exact match?）。

這里順便講下“l(fā)ocation / {}?”和“l(fā)ocation = / {}?”的區(qū)別，“l(fā)ocation / {}?”遵守普通location?的最大前綴匹配，由于任何URI?都必然以“/?”根開頭，所以對于一個URI?，如果有更specific?的匹配，那自然是選這個更specific?的，如果沒有，“/?”一定能為這個URI?墊背（至少能匹配到“/?”），也就是說“l(fā)ocation / {}?”有點默認(rèn)配置的味道，其他更specific的配置能覆蓋overwrite?這個默認(rèn)配置（這也是為什么我們總能看到location / {}?這個配置的一個很重要的原因）。而“l(fā)ocation = / {}?”遵守的是“嚴(yán)格精確匹配exact match?”，也就是只能匹配?http://host:port/?請求，同時會禁止繼續(xù)搜索正則location?。因此如果我們只想對“GET /?”請求配置作用指令，那么我們可以選“l(fā)ocation = / {}?”這樣能減少正則location?的搜索，因此效率比“l(fā)ocation / {}”?高（注：前提是我們的目的僅僅只想對“GET /?”起作用）。

On exact match with literal location without “=” or “^~” prefixes?search is also immediately terminated.

前面我們說了，普通location?匹配完后，還會繼續(xù)匹配正則location?；但是nginx?允許你阻止這種行為，方法很簡單，只需要在普通location?前加“^~?”或“=?”。但其實還有一種“隱含”的方式來阻止正則location?的搜索，這種隱含的方式就是：當(dāng)“最大前綴”匹配恰好就是一個“嚴(yán)格精確（exact match?）”匹配，照樣會停止后面的搜索。原文字面意思是：只要遇到“精確匹配exact match?”，即使普通location?沒有帶“=?”或“^~?”前綴，也一樣會終止后面的匹配。

先舉例解釋下，后面例題會用實踐告訴大家。假設(shè)當(dāng)前配置是：location /exact/match/test.html {?配置指令塊1}，location /prefix/ {?配置指令塊2}?和?location ~ \.html$ {?配置指令塊3}?，如果我們請求?GET /prefix/index.html?，則會被匹配到指令塊3?，因為普通location /prefix/?依據(jù)最大匹配原則能匹配當(dāng)前請求，但是會被后面的正則location?覆蓋；當(dāng)請求GET /exact/match/test.html?，會匹配到指令塊1?，因為這個是普通location?的exact match?，會禁止繼續(xù)搜索正則location?。

To summarize, the order in which directives are checked is as follows:

Directives with the “=” prefix that match the query exactly. If found, searching stops.

All remaining directives with conventional strings. If this match used the “^~” prefix, searching stops.

Regular expressions, in the order they are defined in the configuration file.

If #3 yielded a match, that result is used. Otherwise, the match from #2 is used.

這個順序沒必要再過多解釋了。但我想用自己的話概括下上面的意思“正則?location?匹配讓步普通location?的嚴(yán)格精確匹配結(jié)果；但覆蓋普通?location?的最大前綴匹配結(jié)果”。

It is important to know that nginx does the comparison against?decoded?URIs. For example, if you wish to match “/images/ /test”, then you must use “/images/ /test” to determine the location.

在瀏覽器上顯示的URL?一般都會進行URLEncode?，例如“空格”會被編碼為 ?，但是Nginx?的URL?的匹配都是針對URLDecode?之后的。也就是說，如果你要匹配“/images/ /test?”，你寫location?的時候匹配目標(biāo)應(yīng)該是：“/images/ /test?”。

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 ]

}

上述這4?個location?的配置，沒什么好解釋的，唯一需要說明的是location / {[configuration B]}?，原文的注釋嚴(yán)格來說是錯誤的，但我相信原文作者是了解規(guī)則的，只是文字描述上簡化了下，但這個簡化容易給讀者造成“誤解：先檢查正則location?，再檢查普通location?”。原文：“matches any query, since all queries begin with /,?butregular expressions?and any longer conventional blocks?will be matched first.?”大意是說：“l(fā)ocation / {}?能夠匹配所有HTTP?請求，因為任何HTTP?請求都必然是以‘/?’開始的（這半句沒有錯誤）。但是，正則location?和其他任何比‘/?’更長的普通location?（location / {}?是普通location?里面最短的，因此其他任何普通location?都會比它更長，當(dāng)然location = / {}?和?location ^~ / {}?是一樣長的）會優(yōu)先匹配（matched first?）。”?原文作者說“?but regular expressions will be matched first.?”應(yīng)該只是想說正則?location?會覆蓋這里的?location / {}?，但依然是普通location / {}?先于正則?location?匹配，接著再正則?location?匹配；但其他更長的普通?location?（?any longer conventional blocks?）的確會先于?location / {}?匹配。

Example requests:

/ -> configuration A
/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.

需要提醒下：這里說“in any order?”和“… remain the same?”是因為上面只有一個正則location?。文章前面已經(jīng)說了正則location?的匹配是跟編輯順序有關(guān)系的。

While nested locations are allowed by the configuration file parser, their use is discouraged and may produce unexpected results.

實際上?nginx?的配置文件解析程序是允許?location?嵌套定義的（?location / { location /uri/ {} }?）。但是我們平時卻很少看見這樣的配置，那是因為?nginx?官方并不建議大家這么做，因為這樣會導(dǎo)致很多意想不到的后果。

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?的語法中，可以有“=?”，“^~?”，“~?”和“~*?”前綴，或者干脆沒有任何前綴，還有“@?”前綴，但是后面的分析我們始終沒有談到“@?”前綴。文章最后點內(nèi)容，介紹了“＠”的用途：“@?”是用來定義“Named Location?”的（你可以理解為獨立于“普通location?（location using literal strings?）”和“正則location?（location using regular expressions?）”之外的第三種類型），這種“Named Location?”不是用來處理普通的HTTP?請求的，它是專門用來處理“內(nèi)部重定向（internally redirected?）”請求的。注意：這里說的“內(nèi)部重定向（internally redirected?）”或許說成“forward?”會好點，以為內(nèi)internally redirected?是不需要跟瀏覽器交互的，純粹是服務(wù)端的一個轉(zhuǎn)發(fā)行為。

安裝Nginx

wget ? ??http://nginx.org/download/nginx-1.4.6.tar.gz

tar zxvf nginx-1.1.0.tar.gz

./configure

make

make install

需要注意的是在?configure?這步遇到點小麻煩：

./configure: error: the HTTP rewrite module requires the PCRE library.

安裝?nginx?的時候，?rewrite?模塊默認(rèn)是需要被安裝的。但是?rewrite?模塊所依賴的?PCRE?庫需要額外安裝。

You can either disable the module by using –without-http_rewrite_module

option, or install the PCRE library into the system, or build the PCRE library

statically from the source with nginx by using –with-pcre=<path> option.

解決辦法：?http://apps.hi.baidu.com/share/detail/34331473

先執(zhí)行：?yum -y install pcre-devel openssl openssl-devel??把依賴的東西安裝上。

備注：?PCRE?(Perl Compatible Regular Expressions?)是perl語言正則表達(dá)式。 Nginx的rewrite的正則表達(dá)式采用的是Perl語法集（常識：正則表達(dá)式有不同的語法集，我們常見的grep指令如果需要采用Perl語法集，需要grep -P 來指定）。

location?實例練習(xí)

Nginx?的語法形式是：?location [=|~|~*|^~|@] /uri/ { … }?，意思是可以以“?=?”或“?~*?”或“?~?”或“?^~?”或“?@?”符號為前綴，當(dāng)然也可以沒有前綴（因為?[A]?是表示可選的?A?；?A|B?表示?A?和?B?選一個），緊接著是?/uri/?，再接著是{…}?指令塊，整個意思是對于滿足這樣條件的?/uri/?適用指令塊?{…}?的指令。

上述各種?location?可分兩大類，分別是：“普通?location?”，官方英文說法是?location using???literal strings?和“正則?location?”，英文說法是?location using?regular expressions?。其中“普通?location?”是以“?=?”或“?^~?”為前綴或者沒有任何前綴的?/uri/?；“正則?location?”是以“?~?”或“?~*?”為前綴的?/uri/?。

那么，當(dāng)我們在一個?server?上下文編寫了多個?location?的時候，?Nginx?對于一個?HTTP?請求，是如何匹配到一個?location?做處理呢？用一句話簡單概括?Nginx?的?location?匹配規(guī)則是：“正則?location?”讓步?“普通?location”的嚴(yán)格精確匹配結(jié)果；但覆蓋?“普通?location?”的最大前綴匹配結(jié)果。理解這句話，我想通過下面的實例來說明。

#1?先普通?location?，再正則?location

周邊不少童鞋告訴我，?nginx?是“先匹配正則?location?再匹配普通?location?”，其實這是一個誤區(qū)，?nginx?其實是“先匹配普通?location?，再匹配正則?location?”，但是普通?location?的匹配結(jié)果又分兩種：一種是“嚴(yán)格精確匹配”，官方英文說法是“?exact match?”；另一種是“最大前綴匹配”，官方英文說法是“?Literal strings match the beginning portion of the query – the most specific match will be used.?”。我們做個實驗：

例題?1?：假設(shè)?nginx?的配置如下

server {

???????listen???????9090;

???????server_name??localhost;

??????????????????location / {

???????????root???html;

???????????index??index.html index.htm;

???????????deny all;

???????}

???????location ~ \.html$ {

???????????allow all;

???????}

}

附錄?nginx?的目錄結(jié)構(gòu)是：?nginx->html->index.html

上述配置的意思是：?location / {… deny all;}?普通?location?以“?/?”開始的?URI?請求（注意任何?HTTP?請求都必然以“/?”開始，所以“?/?”的意思是所有的請求都能被匹配上），都拒絕訪問；?location ~\.html$ {allow all;}?正則?location以?.html?結(jié)尾的?URI?請求，都允許訪問。

測試結(jié)果：

[root@web108 ~]#?curl http://localhost:9090/

<html>

<head><title>403 Forbidden</title></head>

<center><h1>403 Forbidden</h1></center>

<hr><center>nginx/1.1.0</center>

</body>

</html>

[root@web108 ~]#?curl http://localhost:9090/index.html

<html>

<head>

<title>Welcome to nginx!</title>

</head>

<center><h1>Welcome to nginx!</h1></center>

</body>

</html>

[root@web108 ~]#?curl http://localhost:9090/index_notfound.html

<html>

<head><title>404 Not Found</title></head>

<center><h1>404 Not Found</h1></center>

<hr><center>nginx/1.1.0</center>

</body>

</html>

[root@web108 ~]#

測試結(jié)果如下：

URI?請求	HTTP?響應(yīng)
curl http://localhost:9090/	403 Forbidden
curl http://localhost:9090/index.html	Welcome to nginx!
curl http://localhost:9090/index_notfound.html	404 Not Found

curl?http://localhost:9090/?的結(jié)果是“?403 Forbidden?”，說明被匹配到“?location / {..deny all;}?”了，原因很簡單HTTP?請求?GET /?被“嚴(yán)格精確”匹配到了普通?location / {}?，則會停止搜索正則?location?；

curl?http://localhost:9090/index.html?結(jié)果是“?Welcome to nginx!?”，說明沒有被“?location / {…deny all;}?”匹配，否則會?403 Forbidden?，但?/index.html?的確也是以“?/?”開頭的，只不過此時的普通?location /?的匹配結(jié)果是“最大前綴”匹配，所以?Nginx?會繼續(xù)搜索正則?location?，?location ~ \.html$?表達(dá)了以?.html?結(jié)尾的都?allow all;?于是接著就訪問到了實際存在的?index.html?頁面。

curl?http://localhost:9090/index_notfound.html???同樣的道理先匹配?location / {}?，但屬于“普通?location?的最大前綴匹配”，于是后面被“正則?location?”?location ~ \.html$ {}?覆蓋了，最終?allow all?；?但的確目錄下不存在index_notfound.html?頁面，于是?404 Not Found?。

如果此時我們訪問?http://localhost:9090/index.txt?會是什么結(jié)果呢？顯然是?deny all?；因為先匹配上了?location / {..deny all;}?盡管屬于“普通?location?”的最大前綴匹配結(jié)果，繼續(xù)搜索正則?location?，但是?/index.txt?不是以?.html結(jié)尾的，正則?location?失敗，最終采納普通?location?的最大前綴匹配結(jié)果，于是?deny all?了。

[root@web108 ~]#?curl http://localhost:9090/index.txt

<html>

<head><title>403 Forbidden</title></head>

<center><h1>403 Forbidden</h1></center>

<hr><center>nginx/1.1.0</center>

</body>

</html>

[root@web108 ~]#

#2?普通?location?的“隱式”嚴(yán)格匹配

例題?2?：我們在例題?1?的基礎(chǔ)上增加精確配置

server {

???????listen???????9090;

???????server_name??localhost;

??????????????????location /exact/match.html {

???????????allow all;

???????}

??????????????????location / {

???????????root???html;

???????????index??index.html index.htm;

???????????deny all;

???????}

???????location ~ \.html$ {

???????????allow all;

???????}

}

測試請求：

[root@web108 ~]#?curl http://localhost:9090/exact/match.html

<html>

<head><title>404 Not Found</title></head>

<center><h1>404 Not Found</h1></center>

<hr><center>nginx/1.1.0</center>

</body>

</html>

[root@web108 ~]#

結(jié)果進一步驗證了“普通?location?”的“嚴(yán)格精確”匹配會終止對正則?location?的搜索。這里我們小結(jié)下“普通?location”與“正則?location?”的匹配規(guī)則：先匹配普通?location?，再匹配正則?location?，但是如果普通?location?的匹配結(jié)果恰好是“嚴(yán)格精確（?exact match?）”的，則?nginx?不再嘗試后面的正則?location?；如果普通?location?的匹配結(jié)果是“最大前綴”，則正則?location?的匹配覆蓋普通?location?的匹配。也就是前面說的“正則?location?讓步普通location?的嚴(yán)格精確匹配結(jié)果，但覆蓋普通?location?的最大前綴匹配結(jié)果”。

#3?普通?location?的“顯式”嚴(yán)格匹配和“?^~?”?前綴

上面我們演示的普通?location?都是不加任何前綴的，其實普通?location?也可以加前綴：“?^~?”和“?=?”。其中“?^~”的意思是“非正則，不需要繼續(xù)正則匹配”，也就是通常我們的普通?location?，還會繼續(xù)搜索正則?location?（恰好嚴(yán)格精確匹配除外），但是?nginx?很人性化允許配置人員告訴?nginx?某條普通?location?，無論最大前綴匹配，還是嚴(yán)格精確匹配都終止繼續(xù)搜索正則?location?；而“?=?”則表達(dá)的是普通?location?不允許“最大前綴”匹配結(jié)果，必須嚴(yán)格等于，嚴(yán)格精確匹配。

例題?3?：“?^~?”前綴的使用

server {

???????listen???????9090;

???????server_name??localhost;

??????????????????location /exact/match.html {

???????????allow all;

???????}

?????????????????location ^~ / {

???????????root???html;

???????????index??index.html index.htm;

???????????deny all;

???????}

???????location ~ \.html$ {

???????????allow all;

???????}

}

把例題?2?中的?location / {}?修改成?location ^~ / {}?，再看看測試結(jié)果：

URI?請求	修改前	修改后
curl http://localhost:9090/	403 Forbidden	403 Forbidden
curl http://localhost:9090/index.html	Welcome to nginx!	403 Forbidden
curl http://localhost:9090/index_notfound.html	404 Not Found	403 Forbidden
curl http://localhost:9090/exact/match.html	404 Not Found	404 Not Found

除了?GET /exact/match.html?是?404 Not Found?，其余都是?403 Forbidden?，原因很簡單所有請求都是以“?/?”開頭，所以所有請求都能匹配上“?/?”普通?location?，但普通?location?的匹配原則是“最大前綴”，所以只有/exact/match.html?匹配到?location /exact/match.html {allow all;}?，其余都?location ^~ / {deny all;}?并終止正則搜索。

例題?4?：“?=?”前綴的使用

server {

???????listen???????9090;

???????server_name??localhost;

??????????????????location /exact/match.html {

???????????allow all;

???????}

?????????????????location = / {

???????????root???html;

???????????index??index.html index.htm;

???????????deny all;

???????}

???????location ~ \.html$ {

???????????allow all;

???????}

}

例題?4?相對例題?2?把?location / {}?修改成了?location = / {}?，再次測試結(jié)果：

URI?請求	修改前	修改后
curl http://localhost:9090/	403 Forbidden	403 Forbidden
curl http://localhost:9090/index.html	Welcome to nginx!	Welcome to nginx!
curl http://localhost:9090/index_notfound.html	404 Not Found	404 Not Found
curl http://localhost:9090/exact/match.html	404 Not Found	404 Not Found
curl http://localhost:9090/test.jsp	403 Forbidden	404 Not Found

最能說明問題的測試是?GET /test.jsp?，實際上?/test.jsp?沒有匹配正則?location?（?location ~\.html$?），也沒有匹配?location = / {}?，如果按照?location / {}?的話，會“最大前綴”匹配到普通?location / {}?，結(jié)果是?deny all?。

#4?正則?location?與編輯順序

location?的指令與編輯順序無關(guān)，這句話不全對。對于普通?location?指令，匹配規(guī)則是：最大前綴匹配（與順序無關(guān)），如果恰好是嚴(yán)格精確匹配結(jié)果或者加有前綴“?^~?”或“?=?”（符號“?=?”只能嚴(yán)格匹配，不能前綴匹配），則停止搜索正則?location?；但對于正則?location?的匹配規(guī)則是：按編輯順序逐個匹配（與順序有關(guān)），只要匹配上，就立即停止后面的搜索。

配置?3.1

server {

???????listen???????9090;

???????server_name??localhost;

???????location ~ \.html$ {

???????????allow all;?

???????}??

???????location ~ ^/prefix/.*\.html$ {

???????????deny all;??

???????}??

}

配置?3.2

server {

???????listen???????9090;

???????server_name??localhost;

??????

???????location ~ ^/prefix/.*\.html$ {

???????????deny all;??

???????}??

?????????????????

??????????????????location ~ \.html$ {

???????????allow all;?

???????}?

}

測試結(jié)果：

URI?請求	配置?3.1	配置?3.2
curl http://localhost:9090/regextest.html	404 Not Found	404 Not Found
curl http://localhost:9090/prefix/regextest.html	404 Not Found	403 Forbidden

解釋：

Location ~ ^/prefix/.*\.html$ {deny all;}?表示正則?location?對于以?/prefix/?開頭，?.html?結(jié)尾的所有?URI?請求，都拒絕訪問；???location ~\.html${allow all;}?表示正則?location?對于以?.html?結(jié)尾的?URI?請求，都允許訪問。?實際上，prefix?的是?~\.html$?的子集。

在“配置?3.1?”下，兩個請求都匹配上?location ~\.html$ {allow all;}?，并且停止后面的搜索，于是都允許訪問，?404 Not Found?；在“配置?3.2?”下，?/regextest.html?無法匹配?prefix?，于是繼續(xù)搜索?~\.html$?，允許訪問，于是?404 Not Found?；然而?/prefix/regextest.html?匹配到?prefix?，于是?deny all?，?403 Forbidden?。

配置?3.3

server {

???????listen???????9090;

???????server_name??localhost;

???????location??/prefix/ {

???????????????deny all;??

???????}??

??????????

???????location??/prefix/mid/ {

???????????????allow all;?

???????}??

}

配置?3.4

server {

???????listen???????9090;

???????server_name??localhost;

?????

???????location??/prefix/mid/ {

???????????????allow all;?

???????}??

??????????????????location??/prefix/ {

???????????????deny all;??

???????}??

}

測試結(jié)果：

URI?請求	配置?3.1	配置?3.2
curl http://localhost:9090/prefix/t.html	403 Forbidden	403 Forbidden
curl http://localhost:9090/prefix/mid/t.html	404 Not Found	404 Not Found

測試結(jié)果表明：普通?location?的匹配規(guī)則是“最大前綴”匹配，而且與編輯順序無關(guān)。

#5 “@”?前綴?Named Location?使用

REFER:??http://wiki.nginx.org/HttpCoreModule#error_page

假設(shè)配置如下：

server {

???????listen???????9090;

???????server_name??localhost;

????????location??/ {

???????????root???html;

???????????index??index.html index.htm;

???????????allow all;

???????}

???????#error_page 404?http://www.baidu.com?#?直接這樣是不允許的

???????error_page 404 = @fallback;

???????location @fallback {

???????????proxy_pass http://www.baidu.com;

???????}

}

上述配置文件的意思是：如果請求的?URI?存在，則本?nginx?返回對應(yīng)的頁面；如果不存在，則把請求代理到baidu.com?上去做個彌補（注：?nginx?當(dāng)發(fā)現(xiàn)?URI?對應(yīng)的頁面不存在，?HTTP_StatusCode?會是?404?，此時error_page 404?指令能捕獲它）。

測試一：

[root@web108 ~]#?curl http://localhost:9090/nofound.html -i

HTTP/1.1 302 Found

Server: nginx/1.1.0

Date: Sat, 06 Aug 2011 08:17:21 GMT

Content-Type: text/html; charset=iso-8859-1

Location: http://localhost:9090/search/error.html

Connection: keep-alive

Cache-Control: max-age=86400

Expires: Sun, 07 Aug 2011 08:17:21 GMT

Content-Length: 222

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>

<title>302 Found</title>

</head><body>

<h1>Found</h1>

<p>The document has moved <a href=”http://www.baidu.com/search/error.html”>here</a>.</p>

</body></html>

[root@web108 ~]#

當(dāng)我們?GET /nofound.html?發(fā)送給本?nginx?，?nginx?找不到對應(yīng)的頁面，于是?error_page 404 = @fallback?，請求被代理到?http://www.baidu.com?，于是?nginx?給?http://www.baidu.com?發(fā)送了?GET /nofound.html?，但/nofound.html?頁面在百度也不存在，百度?302?跳轉(zhuǎn)到錯誤頁。

直接訪問?http://www.baidu.com/nofound.html?結(jié)果：

[root@web108 ~]#?curl http://www.baidu.com/nofound.html -i

HTTP/1.1 302 Found

Date: Sat, 06 Aug 2011 08:20:05 GMT

Server: Apache

Location: http://www.baidu.com/search/error.html

Cache-Control: max-age=86400

Expires: Sun, 07 Aug 2011 08:20:05 GMT

Content-Length: 222

Connection: Keep-Alive

Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>

<title>302 Found</title>

</head><body>

<h1>Found</h1>

<p>The document has moved <a href=”http://www.baidu.com/search/error.html”>here</a>.</p>

</body></html>

[root@web108 ~]#

測試二：訪問一個?nginx?不存在，但?baidu?存在的頁面

[root@web108 ~]#?curl http://www.baidu.com/duty/ -i

HTTP/1.1 200 OK

Date: Sat, 06 Aug 2011 08:21:56 GMT

Server: Apache

P3P: CP=” OTI DSP COR IVA OUR IND COM ”

Set-Cookie: BAIDUID=5C5D2B2FD083737A0C88CA7075A6601A:FG=1; expires=Sun, 05-Aug-12 08:21:56 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1

Set-Cookie: BAIDUID=5C5D2B2FD083737A2337F78F909CCB90:FG=1; expires=Sun, 05-Aug-12 08:21:56 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1

Last-Modified: Wed, 05 Jan 2011 06:44:53 GMT

ETag: “d66-49913b8efe340″

Accept-Ranges: bytes

Content-Length: 3430

Cache-Control: max-age=86400

Expires: Sun, 07 Aug 2011 08:21:56 GMT

Vary: Accept-Encoding,User-Agent

Connection: Keep-Alive

Content-Type: text/html

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”

“http://www.w3.org/TR/html4/loose.dtd”>

。。。。

</body>

</html>

顯示，的確百度這個頁面是存在的。

[root@web108 ~]#?curl http://localhost:9090/duty/ -i

HTTP/1.1 200 OK

Server: nginx/1.1.0

Date: Sat, 06 Aug 2011 08:23:23 GMT

Content-Type: text/html

Connection: keep-alive

P3P: CP=” OTI DSP COR IVA OUR IND COM ”

Set-Cookie: BAIDUID=8FEF0A3A2C31D277DCB4CC5F80B7F457:FG=1; expires=Sun, 05-Aug-12 08:23:23 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1

Set-Cookie: BAIDUID=8FEF0A3A2C31D277B1F87691AFFD7440:FG=1; expires=Sun, 05-Aug-12 08:23:23 GMT; max-age=31536000; path=/; domain=.baidu.com; version=1

Last-Modified: Wed, 05 Jan 2011 06:44:53 GMT

ETag: “d66-49913b8efe340″

Accept-Ranges: bytes

Content-Length: 3430

Cache-Control: max-age=86400

Expires: Sun, 07 Aug 2011 08:23:23 GMT

Vary: Accept-Encoding,User-Agent

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”

“http://www.w3.org/TR/html4/loose.dtd”>

<html>

。。。

</body>

</html>

當(dāng)?curl http://localhost:9090/duty/ -i?時，?nginx?沒找到對應(yīng)的頁面，于是?error_page = @fallback?，把請求代理到?baidu.com?。注意這里的?error_page = @fallback?不是靠重定向?qū)崿F(xiàn)的，而是所說的“?internally redirected?（forward?）”。

轉(zhuǎn)載于:https://www.cnblogs.com/chuhanlong/p/5049131.html

總結(jié)

以上是生活随笔為你收集整理的关于一些对location认识的误区(转)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇： OpenResty 反向代理的用法与技巧
下一篇： Swift - 14 - 字符串的基础操