The Location Context

The next context that you will deal with regularly is the location context. Location contexts share many relational qualities with server contexts. For example, multiple location contexts can be defined, each location is used to handle a certain type of client request, and each location is selected by virtue of matching the location definition against the client request through a selection algorithm.

While the directives that determine whether to select a server block are defined within the server context itself, the component that decides on a location’s ability to handle a request is located in the location definition itself.

location optional_modifier location_match {
    . . .
}

The location_match above defines what Nginx should check the request URI against. The existence or nonexistence of the modifier in the above example affects the way that the Nginx attempts to match the location block.

• (none): If no modifiers are present, the location is interpreted as a prefix match. This means that the location given will be matched against the beginning of the request URI to determine a match.
• =: If an equal sign is used, this block will be considered a match if the request URI exactly matches the location given.
• ~: If a tilde modifier is present, this location will be interpreted as a case-sensitive regular expression match.
• ~*: If a tilde and asterisk modifier is used, the location block will be interpreted as a case-insensitive regular expression match.
• ^~: If a carat and tilde modifier is present, and if this block is selected as the best non-regular expression match, regular expression matching will not take place.

Location blocks live within server contexts and, unlike server blocks, can be nested inside one another.

# main context
server {
    # server context
    location /match/criteria {
        # first location context
    }
    location /other/criteria {
        # second location context
        location nested_match {
            # first nested location
        }
        location other_nested {
            # second nested location
        }
    }
}

While server contexts are selected based on the requested IP address/port combination and the host name in the “Host” header, location blocks further divide up the request handling within a server block by looking at the request URI. The request URI is the portion of the request that comes after the domain name or IP address/port combination.

So, if a client requests http://www.example.com/blog on port 80, the http, www.example.com, and port 80 would all be used to determine which server block to select. After a server is selected, the /blog portion (the request URI), would be evaluated against the defined locations to determine which further context should be used to respond to the request.

Many of the directives you are likely to see in a location context are also available at the parent levels. New directives at this level allow you to reach locations outside of the document root (alias), mark the location as only internally accessible (internal), and proxy to other servers or locations (using http, fastcgi, scgi, and uwsgi proxying).