- [Instructor] Welcome to Module Four of the NGINX Core e-Learning course. This module covers the location context. After completing this module, you will be able to identify the location block that responds to requests, identify location processing rules, and configure a simple web server that serves static pages and images. The location block directive matches the http request URI against a string value to process an http request. A location block is optional. Its intention is to define precise request destinations instead of solely relying on the server block. For example, in the request shown here, /app1, plus the argument after it is the request URI because it comes after the host name. Once NGINX has chosen which server to respond with, it then matches the location block based on the URI of the request. There are two types of location blocks: prefix and regex. A prefix refers to the immediate characters that come after the host name of the http request. A regex refers to a Perl regular expression. NGINX checks all location blocks, unless we tell it not to with a specific location modifier. We will show some of these location modifiers in the next slide. Location modifiers augment the location processing behavior. The tilde and asterisk indicates a case insensitive regular expression.

The tilde indicates a case sensitive regular expression. The caret tilde prevents regular expression matching. In other words, if a matching prefix location contains this modifier, NGINX won't check for regular expression locations. Similar to the server name directive, NGINX checks all prefix locations and then selects the longest match. In other words, the most specific matching prefix location. In our example, a client makes an http request and once the server block has been selected, the location blocks are used. NGINX checks the first location block and finds an exact match of /gallery. However, the second location block contains a longer matching prefix. Therefore, the second location serves the client response. The order of prefix location doesn't matter. We could switch the order of these two prefix locations and NGINX would still select the more specific match, which in this case is /gallery/images. Regex locations are used after prefix locations. It's a best practice to list your regex locations in order of precedence at the bottom of your configuration. 

This is because once a regular expression matches, NGINX does not continue to process other regular expression location blocks. However, in this example, we have a regex location nested between two prefix locations. As shown in the second location block, the tilde asterisk, after the location directive, means NGINX interprets this location as a case instance that of a regular expression. More specifically, caret backslash dot refers to all characters after the host name but before a dot. Parentheses png pipe jpeg parentheses dollar sign means followed by the file extension types png or jpeg. Note that the second location block has a caret symbol at the beginning of a regular expression. This is Perl syntax and it indicates the beginning of a regular expression. The parentheses in the regular expression indicate a capture group, meaning NGINX evaluates any present values. The dollar sign indicates the end of a regular expression. The third location starts with a caret tilde symbol which indicates that no regular expression matching should take place if this prefix is the best match. In this example, the sample request is http www.example.com/app1/index.php. Our server configuration listens on port 80 with a root content directory of /user/share/NGINX/html. The configuration has three location blocks, two of which are prefixed and one which is a regular expression. NGINX checks the slash prefix first. This is a valid match. NGINX didn't check the second prefix location. This is the third listed location. Since the request URI is longer, the second prefix, /app1 is a better match. Our /app1 prefix also contains a location modifier, the caret tilde modifier. This indicates there should be no regular expression matching if the location block is a match. Therefore, NGINX doesn't use the regular expression in the middle to serve the response. The second example uses a slightly different configuration from our previous example. The /app1 prefix no longer contains a caret tilde modifier. 

In this case, NGINX uses the regex location to serve the response. After checking both prefix locations, it checks the regular expression location. This particular regular expression looks for any character before a dot followed by either png or jpeg. If our /app1 prefix location were /app1/index.php, it would serve the response because /app1/index.php provides an exact match for the request. As written, this regular expression may still cause problems because its capture group is too general. It's a best practice to construct your capture groups to target a specific portion of the URI rather than everything before a dot. In this example, which prefix location is the closest match for the http request. The answer is the second location block. /app1/ was the closest match because it is more specific than the other two prefix locations. In summary, NGINX checks location blocks to determine which will serve a response. NGINX chooses the most specific or longest prefix match if there are multiple location blocks. NGINX first checks the prefix type location blocks for a match, and if it finds a match, there may be a modifier that tells it not to check regular expressions also listed. If there is no such modifier, NGINX also checks the regex locations for a match in the order they are listed. Once it finds a match, it stops checking. So a best practice is to list these in order of precedence. Thank you for completing this module on serving content using the location context.