nginx location说明

原文
引用

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

Sets configuration depending on a request 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 possible compression of two or more adjacent slashes into a single slash.

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 matching prefix is selected and remembered. Then regular expressions are checked, in the order of their appearance in 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 the configuration of the prefix location remembered earlier is used.

location blocks can be nested, with some exceptions mentioned below.

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.

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.

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.

    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 were not 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 match configuration C, the “/images/1.gif” request will match configuration D, and the “/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 of proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, or memcached_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 be defined like this:

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

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



uri匹配规则
1 先decode uri
2 解析 "."和".."相对路径
3、多个"/"会被合并为一个"/"
4 支持字符串前缀(以xxxx字符开头的uri)匹配和正则匹配
5 以“~*”和“~”开头为正则匹配,“~*”正则大小写不敏感,“~”大小写精确匹配
6 如果匹配到的最长的字符串前缀匹配前有“^~”,则不再匹配正则表达式

一次匹配过程
先搜索字符串前缀匹配,最长的字符串前缀优先匹配,作为临时结果,继续匹配正则,匹配到第一个正则表达式后,匹配结束,使用这个正则表达式的配置,若未搜到正匹配的正则,则使用临时匹配上的字符串匹配

对示例的讲解
引用

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 match configuration C, the “/images/1.gif” request will match configuration D, and the “/documents/1.jpg” request will match configuration E.


“/”精确匹配了 配置A

“/index.html”字符串前缀 匹配了配置B,以"/"开头的url

“/documents/document.html”字符串前缀 匹配了配置C,以"/documents/"开头的匹配,
同时也匹配了 配置规则B,以"/"开头的URL,字符串前缀匹配以最长匹配优先,所以最终
匹配结果为配置C,


“/images/1.gif” 匹配配置D和E,但是D配置在前,因此结果为D

“/documents/1.jpg” 匹配配置C和E,但C是字符串前缀匹配,会继续进行正则匹配E,匹配到E后以E为匹配结果,匹配结束


猜你喜欢

转载自powertech.iteye.com/blog/2241732