Nginx-http Configuration, the location Block

Nginx offers you the possibility to fine-tune your config 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.

Location Modifier

Nginx allows define location blocks by specifying a pattern that would be matched against the requested doc Ument URI.

server {
server_name website.com;
location/admin/{
# The 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 would define the the the-the-the-the-the-the-the-the- Pecified 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 = modifier

The requested document URI must match the specified pattern exactly. The pattern here was 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:

• Applies to HTTP://WEBSITE.COM/ABCD (exact match)
• Applies to Http://website.com/ABCD (It is case-sensitive if your operating system uses a case-sensitive filesyste M
• Applies to http://website.com/abcd?param1&param2 (regardless of query string arguments)
• Does not apply to http://website.com/abcd/ (trailing slash)
• Does not apply to HTTP://WEBSITE.COM/ABCDE (extra characters after the specified pattern)

No modifier

The requested document URI must begin with the specified pattern. Regular Expressions:

server {
server_name website.com;
LOCATION/ABCD {
[...]
}
}

The configuration in the location block:

• Applies to HTTP://WEBSITE.COM/ABCD (exact match)
• Applies to Http://website.com/ABCD (It is case-sensitive if your operating system uses a case-sensitive filesyste M
• Applies to http://website.com/abcd?param1&param2 (regardless of query string arguments)
• Applies to http://website.com/abcd/ (trailing slash)
• Applies to Http://website.com/abcde (extra characters after the specified pattern)

The ~ modifier

The requested URI must is 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, the pattern must begin (^) with / , be followed by ABC, and Finish ($) with D. Consequently, the configuration in the location block:

• Applies to HTTP://WEBSITE.COM/ABCD (exact match)
• Does not apply to Http://website.com/ABCD (case-sensitive)
• Applies to http://website.com/abcd?param1&param2 (regardless of query string arguments)
• Does not apply to http://website.com/abcd/ (trailing slash) due to the specified regular expression
• Does not apply to HTTP://WEBSITE.COM/ABCDE (extra characters) due to the specified regular expression

With operating systems such as Microsoft Windows, ~ and ~* is both case-insensitive, as the OS uses a case-insensitive fi Lesystem.

The ~* modifier

The requested URI must is a case-insensitive match to the specified regular expression:

server {
server_name website.com;
Location ~* ^/abcd$ {
[...]
}
}

The regular expression used in the example are similar to the previous one. Consequently, the configuration in the location block:

• Applies to HTTP://WEBSITE.COM/ABCD (exact match)
• Applies to Http://website.com/ABCD (case-insensitive)
• Applies to http://website.com/abcd?param1&param2 (regardless of query string arguments)
• Does not apply to http://website.com/abcd/ (trailing slash) due to the specified regular expression
• Does not apply to HTTP://WEBSITE.COM/ABCDE (extra characters) due to the specified regular expression

The ^~ modifier

Similar to the No-symbol behavior, the location URI must begin with the specified pattern. The difference is so if the pattern is matched, Nginx stops searching for other patterns (read the sections below about S Earch order and priority).

The @ modifier

Defines a named location block. These blocks cannot is accessed by the client, but only by internal requests generated by other directives, such as tr Y_files or error_page.

Search Order and Priority

Since it ' s possible to define multiple location blocks with different patterns, you need to understand that's when Nginx rec Eives a request, it searches for the location block, the best matches the requested URI:

server {
server_name website.com;
location/files/{
# applies to any requ EST starting with "/files/"
# for Example/files/doc.txt,/files/,/files/tem p/
"
location =/files/{
applies to the exact request to"/files/"
# 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's an exact match).

The order you established in the configuration file (placing the /files/ block before the =/files/ Block) is irrelevant. Nginx would search for matching patterns in a specific order:

2. location blocks with the = modifier:if The specified string exactly matches the requested URI, Nginx re Tains the location block.
4. location blocks with no modifier:if the specified string exactly matches the requested URI, Nginx retains the location block.
6. location blocks with the ^~ modifier:if The specified string matches the beginning of the requested URI , Nginx retains the location block.
8. location blocks with ~ or ~* modifier:if The regular expression matches the requested URI, Ngi NX retains the location block.
10. location blocks with no modifier:if the specified string matches the beginning of the requested URI, Nginx Retai NS The location block.

Case 1:

server {
server_name website.com;
Location/doc {
[...] # requests Beginnin G with "/doc"
"
location ~* ^/ document$ {
[...] # requests exactly matching"/document "
}
}

You might wonder:when a client requests http://website.com/document, which of these where is 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. The second location block would apply as the ~* modifier have priority over the other.

Case 2:

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.

Case 3:

server {
server_name website.com;
location ^~/doc {
[...] # requests Beginn ing 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 ^~ have priority over ~*. As a result, any request with a URI beginning with /doc would 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