标签：
Nginx offers you the possibility to fine-tune your configuration down to three levels — at the protocollevel (http block), the server
level (server block), and the requested URI level (location block). Let us now detail the latter.
Nginx allows you to define location blocks by specifying a pattern that will be matched against the requested document URI.
server {
server_name website.com;
location /admin/ {
# The configuration you place here only applies to
# http://website.com/admin/
}
}
Instead of a simple folder name, you can indeed insert complex patterns. The syntax of the location block is:
location [=|~|~*|^~|@] pattern { ... }
The first optional argument is a symbol called location modifier that will define the way Nginx matches the specified pattern and also defines the very nature of the pattern (simple string or regular expression). The following paragraphs detail the different modifiers and their behavior.
The requested document URI must match the specified pattern exactly. The pattern here is limited to a simple literal string; you cannot use a regular expression:
server {
server_name website.com;
location = /abcd {
[…]
}
}
The configuration in the location block:
The requested document URI must begin with the specified pattern. You may not use regular expressions:
server {
server_name website.com;
location /abcd {
[…]
}
}
The configuration in the location block:
The requested URI must be a case-sensitive match to the specified regular expression:
server {
server_name website.com;
location ~ ^/abcd$ {
[…]
}
}
The ^/abcd$ regular expression used in this example specifies that the pattern must begin (^) with /, be followed by abc, and finish ($) with d. Consequently, the configuration in the location block:
With operating systems such as Microsoft Windows, ~ and ~* are both case-insensitive, as the OS uses a case-insensitive filesystem.
The requested URI must be a case-insensitive match to the specified regular expression:
server {
server_name website.com;
location ~* ^/abcd$ {
[…]
}
}
The regular expression used in the example is similar to the previous one. Consequently, the configuration in the location block:
Similar to the no-symbol behavior, the location URI must begin with the specified pattern. The difference is that if the pattern is matched, Nginx stops searching for other patterns (read the section below about search order and priority).
Defines a named location block. These blocks cannot be accessed by the client, but only by internal requests generated by other directives, such as try_files or error_page.
Since it‘s possible to define multiple location blocks with different patterns, you need to understand that when Nginx receives a request, it searches for the location block that best matches the requested URI:
server {
server_name website.com;
location /files/ {
# applies to any request starting with "/files/"
# for example /files/doc.txt, /files/, /files/temp/
}
location = /files/ {
# applies to the exact request to "/files/"
# and as such does not apply to /files/doc.txt
# but only /files/
}
}
When a client visits http://website.com/files/doc.txt, the first location block applies. However, when they visit http://website.com/files/, the second block applies (even though the first one matches) because it has priority over the first one (it is an exact match).
The order you established in the configuration file (placing the /files/ block before the = /files/ block) is irrelevant. Nginx will search for matching patterns in a specific order:
server {
server_name website.com;
location /doc {
[…] # requests beginning with "/doc"
}
location ~* ^/document$ {
[…] # requests exactly matching "/document"
}
}
You might wonder: when a client requests http://website.com/document, which of these two location blocks applies? Indeed, both blocks match this request. Again, the answer does not lie in the order in which the blocks appear in the configuration files. In this case, the second location block will apply as the ~* modifier has priority over the other.
server {
server_name website.com;
location /document {
[…] # requests beginning with "/document"
}
location ~* ^/document$ {
[…] # requests exactly matching "/document"
}
}
The question remains the same — what happens when a client sends a request to download http://website.com/document? There is a trick here. The string specified in the first block now exactly matches the requested URI. As a result, Nginx prefers it over the regular expression.
server {
server_name website.com;
location ^~ /doc {
[…] # requests beginning with "/doc"
}
location ~* ^/document$ {
[…] # requests exactly matching "/document"
}
}
This last case makes use of the ^~ modifier. Which block applies when a client visits http://website.com/document? The answer is the first block. The reason being that ^~ has priority over ~*. As a result, any request with a URI beginning with /doc will be affected to the first block, even if the request URI matches the regular expression defined in the second block.
Nginx - HTTP Configuration, the Location Block
标签：
原文地址：http://www.cnblogs.com/huey/p/5745202.html
