Shulou(Shulou.com)06/02 Report--

What is the use of Location in Nginx? aiming at this question, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

Text

Syntax:

Grammar

Location [= | ~ | ~ * | ^ ~] uri {.}

Location @ name {...}

Default:

Default

-

Context:

Use scenarios / contexts

Server, location

Sets configuration depending on a request URI. Configuration rules based on 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. Matching takes effect for normal uri decoded from text in "% xx" format, resolving relative path references "." And "..", and compress 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 can be defined with a prefix string or a regular expression. Regular expressions are preceded by ~ * modifiers (case-insensitive matching) or ~ modifiers (case-sensitive matching). To find a location,nginx that matches a given request, first check the location with the prefix string (also known as the prefix location). Among them, the location with the longest matching prefix will be selected and recorded. Then check the regular expressions in the order in which they are listed in the configuration file. The search for regular expressions will be terminated at the first match, and then the corresponding configuration will be used. If the regular expression is not hit, the previously recorded prefix location is used.

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

Location modules can be nested. Here are some exceptions:

For case-insensitive operating systems such as macOS and Cygwin, matching with prefix strings ignores a case (0.7.7). However, comparison is limited to one-byte locales. For case-insensitive operating systems, such as macOS and Cygwin, matching prefix strings ignores an uppercase (version 0.7.7). However, the comparison is limited to a single byte.

Regular expressions can contain captures (0.7.40) that can later be used in other directives. Regular expressions can contain matches that can be used in subsequent instructions. (version 0.7.40)

If the longest matching prefix location has the "^ ~" modifier then regular expressions are not checked. If the longest matching prefix location has a ^ ~ modifier, then the regular expression will not be 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.

At the same time, it is possible to define a precise match between uri and location using the'= 'modifier. If an exact match is found, the query is terminated. For example, if a'/ 'request occurs frequently, defining' location = / 'will speed up the processing of those requests because the search ends after the first comparison. This kind of location obviously cannot contain nested location.

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.

In versions 0.7.1 to 0.8.41, if a request hits the prefix location that does not contain the'='or'^ ~ 'modifiers, the search is terminated and the regular expression is not checked.

Let's illustrate the above by an example: let's show the above with 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'/ 'request will match to configuration A (exact match)

The'/ index.html' request will match to configuration B (no exact match, no prefix match, no regular match, and finally the default match)

/ documents/document.html' request will hit configuration C (no exact match, prefix match / documents/, continues to find regular match, no hit, use prefix match)

'/ images/1.gif' request will hit configuration D (did not hit the exact match, hit the prefix match ^ ~ / images/, with the ^ ~ modifier, do not find the regular match, but directly use the prefix match)

The / documents/1.jpg' request will hit configuration E (missed the exact match and hit / documents and ~ *\. (gif | jpg | jpeg) $, the latter is the longest, is recorded, continues to find the regular match, does not hit, and configures E with the longest prefix previously recorded.

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.

The'@ 'prefix is equivalent to naming a location. This location will not be used to handle regular requests, but will be used to request redirects. They cannot be nested, nor can they contain nested location.

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, memcached_pass, or grpc_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:

If a location uses a prefix string and ends with a slash\, and these requests are processed by one of proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass, or grpc_pass, then special processing will be performed. When responding to a request with a uri equal to this string but without a final slash\, a permanent redirect to the requested uri with a 301 status code is returned with the last slash\. If you don't want this, the exact match of uri and location can be defined as follows: (so it doesn't jump to 301s)

Location / user/ {proxy_pass http://user.example.com;}location = / user {proxy_pass http://login.example.com;} Summary 1, syntax

Modifier (modifier)

Location [= | ~ | ~ * | ^ ~] uri {.}

2, classification

According to different modifiers, they can be divided into two categories.

2.1 prefix location (prefix location)

2.1.1 ordinary location without modifiers, such as location / abc, location / abc/

2.1.2 exact match location with =, for example, location = / abc

2.1.3 an irregular expression location with ^ ~ that begins with a regular string, such as location ^ ~ / abc

2.2 regular expression location (regular expressions location)

2.2.1 ~ case-sensitive regular location

2.2.2 ~ * case-insensitive regular location

3, matching rules

3.1 nginx first checks the prefix location

3.1.1 if hit, the location with the longest matching string will be selected and recorded.

3.1.1.1 if the modifier of the longest prefix matching location is ^ ~, the regular location will not be checked and the location will be selected as the final location. If not, proceed to the next regular match.

3.1.2 if you miss, proceed to the next regular match.

3.2 if there is a regular location, follow the order of configuration (important!) Match URI in turn.

3.2.1 if a matching regular location is found, it does not go any further and selects the location as the final result.

3.2.2 if no matching regular location is found, the previously recorded prefix location, if any, is used.

3.3 if a precise matching location exists and the requested uri matches it exactly, select the exact matching location as the final location.

4, priority

Precise matching > ^ ~ modifier longest prefix matching > regular matching > non-modifier ordinary longest prefix matching > Universal matching /

5, other

Note that there cannot be both the ^ ~ modifier prefix location with the same string and the ordinary prefix location without modifiers in the same Server, as follows

Server {listen 80; server_name www.test1.com; root/ opt/wwwroot/test; location / fullpath {echo 'prefix fullpath with no modifier';} location ^ ~ / fullpath {echo' prefix fullpath with ^ ~ modifier';}}

If both are turned on at the same time, an emerg level error will be reported when the nginx-t command checks the nginx configuration

At 14:01:52 on 2019-11-05 [emerg] 22355 / 22355: duplicate location "/ fullpath" in / etc/nginx/sites-enabled/default:165 the answers to the questions about the usefulness of Location in Nginx are shared here. I hope the above content can be of some help to you all. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.