i. Nginx Location Directive
1. Nginx location directive syntax:
Revising! Location blocks determine how to process the request URI (the segment of the request that follows after the domain name or IP address/port), and they reside within server blocks (or other location blocks with some restrictions).
Typically, location blocks take the following syntax:
The modifier in the above is optional, yet its existence affects the way that the Nginx treats a URL.
2. Interpret few most common modifiers as follows:
a. Exact Match Using Equal Sign =
The equal sign in the following location block forces an exact match with the path requested and then stops searching for any more matches.
=In order to reply to a request URI that looks like /images, the above block will always be used. It will not be used to respond to a request URI for /images/index.html.
The above location block will match with the URL https://server1Raneem.com/images ,while the URL https://server1Raneem.com/images/index.html or https://server1Raneem.com/images/ will not be matched.
š” If a request is made to a location that is matched by a particular location block, and that request is fulfilled using an index page, then an internal redirect will occur to another location that will actually handle the request. This is because the original location block may not have been configured to handle the request in the way that is needed for the index page (see the supplement below).
Supplement:
For example, suppose there is a location block that is configured to serve static files:
location /static {
alias /var/www/example.com/static;
}
If a request is made to http://example.com/static/, and there is an index.html file in the /var/www/example.com/static/ directory, Nginx will serve the index.html file as the response to the request. However, because the original location block is configured to serve static files, it may not be able to handle the request in the way that is needed for the index.html file. In this case, an internal redirect will occur to another location that will actually handle the request for the index.html file.
b. Case-Sensitive Regex Match Using Tilde Sign ~
In Nginx, the tilde symbol ~ is used to indicate a case-sensitive RegEx match in a location directive. When the ~ symbol is used, Nginx will use a RegEx to match the request URI against the pattern specified in the location directive.
Here's an example of using the ~ symbol in a location directive to perform a case-sensitive RegEx match:
~In the example above, the RegEx /articles/([0-9]+)/ matches URLs that contain the string "/articles/" followed by one or more digits.
Since the ~ symbol is used, the RegEx match is case-sensitive, and the RegEx pattern must match the case of the characters in the request URI exactly. For example, the RegEx ~ /articles/ would not match a request for a URL that contains "/Articles/" or "/articles123/".
c. Case-InSensitive RegEx Match Using Tilde-Asterisk Sign ~*
c.1 Location block for image/css/js file types:
The RegEx ~* \.(jpg|jpeg|png)$ bellow specifies that requests for URLs that end with ".jpg", ".jpeg", or ".png" should be matched by this location block. The forward slash is not used as a modifier here, but rather as a delimiter within the RegEx (e.g., /turtle.jpg and /human.png could be handled by the following block):
c.2 Matching URLs that contain a certain string:
Figure c.2 below illustrates a location directive that matches requests for URLs that contain either "admin" or "login", regardless of case.
c.3 Matching URLs that start with a certain string:
Figure c.3 below illustrates a location directive that will match requests for URLs which start with "/articles", regardless of case.
š”The case-sensitive RegEx match using the ~ symbol is different from the case-insensitive RegEx match using the ~* symbol, which matches the request URI against the regular expression pattern regardless of case.
d. Case-Sensitive non-RegEx/RegEx Match Using Tilde-Anchor Sign ^~
The ^~ character is used to indicate that a location block should be matched using a non-regular expression match. When Nginx encounters a location block with the ^~ character, it will first try to match the request URL exactly as it appears in the location block. If there is an exact match, Nginx will use the configuration directives specified in that location block to handle the request.
If there is no exact match, Nginx will continue searching for a regular expression match. If a regular expression match is found, Nginx will use the configuration directives specified in that location block instead.
d.1 For example, the following location directive uses the ^~ modifier to match requests for URLs that start with "/images/":
In Figure d.1 above, the ^~ modifier is used to specify that requests for URLs that start with "/images/" should be matched by this location block. Because the ^~ modifier is used, Nginx will give priority to this location block over any other location blocks that may also match the request. This means that if there is another location block that matches the request, but does not have the ^~ modifier, it will not be used to handle the request.
d.2 The following location directive uses the ~^ modifier to match requests for URLs that start with "/articles/" followed by one or more digits:
Because the ~^ modifier is used, the RegEx match is case-sensitive, and the RegEx pattern must match the case of the characters in the prefix string exactly. For example, the RegEx ~^ /articles/ would not match a request for a URL that starts with "/Articles/" or "/articles123/".
2.1 Exceptions:
2.1.1 No modifier The location will be interpreted as a prefix match. This implies that the request URI's first segment will be compared to the location provided to determine a match.
2.1.2 Neither modifier nor URI
In the example bellow, the prefix / matches all requests; yet it will only be used as a last option if no matches are discovered.
The forward slash is not being used as a modifier or URI, but rather as a catch-all for all requests. The directives inside the location block are applied to all requests, regardless of the URI.
3. Redirect URL (Rules)
There are times when specific instructions inside the chosen location cause a new location search to be initiated. The "only one location block" exceptions could have an impact on how the request is actually fulfilled and could not match your expectations while you were creating your location blocks. This kind of internal redirect can be caused by a number of directives, including:
index
try_files
rewrite
error_page
The following is an example:
Last updated