- [Presenter] Welcome to module 3 of the NGINX Core e-learning course. This module covers the server context. After completing this module, you will be able to identify the server block that will respond to a request. Now that you understand the directive types and basic inheritance models, let's discuss how NGINX selects a server block to process a request and server response. The two main steps are server selection and request/response handling. For server selection, NGINX selects a server block based on the listen directive and/or the server name directive. The listen directive represents an IP address or port interface and the server name directive represents a domain or host name. The listen directive defines the listening IP address and port for a virtual server. 

NGINX applies default values where directives are missing values. When NGINX processes a request, it first looks at the IP and port definition of the request and attempts to match it against a listen directive. The listen directive can be set to a standalone port interface, an IP address and port combination, a standalone IP address, a UNIX socket. This last option generally only applies when passing requests between application servers. If no listen directive exists, the server will listen on port 80 by default. NGINX translates all incomplete listen directives by substituting missing values so that it can resolve each server directive by an IP and port. So some examples of these translations are a server with no listen directive uses the value 0.0.0.80. The 0.0.0.0 IP address means listen on all IP addresses. A server with a fully defined listen directive of 127.0.0.1:8080 uses that address. 

A listen directive set to an IP address, 127.0.0.2, with no port, becomes 127.0.0.2:80. A listen directive set to a port 80 with no IP address becomes 0.0.0.0:80. When using a UNIX socket, you must indicate an absolute path to that socket. NGINX attempts to collect a list of server definitions that match the HTTP request headers based on IP and port. A listen directive using 0.0.0.0 as the IP, which means it essentially matches any interface, is not selected if there are matching listen directives that list specific IP addresses. Note that if there are multiple listen directives, one specifying an IP, the other a port, the IP address always wins. In this example, imagine we have requests one through four as shown on the left side of the slide. Which server block will serve the correct response for each request? Answer, the first server block serves the response to the first request because it's an exact match and NGINX always chooses the highest level of specificity in terms of matching. The second server block serves the response to the second and third requests. Even though the third request specifies port 80, the IP is a match for the second server. And because NGINX substitutes default values, the second server block actually listens on port 80. The third server block serves the response to the fourth request only if the domain, example.com, doesn't resolve to the IP address, 192.168.1.10 when resolved through the domain name system. The server name directive examines the host header field of an HTTP request. 

The host header typically contains a domain name which resolves to an IP address stored in the domain name system. NGINX only evaluates the server name directive when the listen directive contains the same level of specificity in terms of IP and/or port definitions in its configuration file. For instance, if the client makes a request for example.com, but NGINX detects two virtual servers listening on the same IP, it then examines the host header field in order to determine a correct match. And in this example, it uses the second server block because its server name directive is an exact match for the host header, example.com. The server name directive is used to provide additional specificity. NGINX selects the longest-matching server name to respond to a request. If there is no match for a server name, NGINX cycles through its selection rules. In order, they are: an exact string match. If there are multiple exact string matches, NGINX selects the first one in the configuration file. If NGINX finds no exact match, it checks for leading wildcards in the server name, If NGINX finds no leading wildcard match, it checks for the trailing wildcards in the server name. If NGINX can't find a trailing wildcard match, it checks against the first Perl regular expression match. In this example, the request is host1.example.com. The host header field is an exact match of the second server's server name directive, so the second server block serves the response. However, if the request were www.example.com, then the first server block would serve the response. In this example, the request is www.example.org. There is no exact match, so NGINX uses the second server block because it contains a match for a leading wildcard. Even though the third server block is technically correct, the second server block is a more specific match than the third server block. If there is no leading wildcard match, NGINX then checks against trailing wildcards. If there are no exact or wildcard matches, NGINX checks next against Perl regular expressions. Regular expression matching behaves differently than exact or wildcard matches. Instead of finding the most specific or best match, regular expressions execute in the order they appear in the configuration. Therefore, in this example, even though the second server block is a more specific regular expression, the first server block is a valid match and serves the response as a result. The default server parameter is a parameter of the listen directive. It defines which server block acts as the default server block. The default server block serves a response when NGINX can't determine the correct server block based on either listen or server name directive values. If there is no default server parameter defined on any listen directive, NGINX selects the first server block in the configuration to serve the response. The reason default server is a parameter of the listen directive rather than the server name directive is that NGINX checks the host header field second. Therefore, NGINX needs an IP address to fall back to in case the host header field value is empty, or doesn't match any server name directive value. 

In summary, the listen directive defines the IP port combination the virtual server listens on. NGINX substitutes missing values in the listen directive. When the listen directive is evaluated, IP takes precedence over port. The server name directive examines the host header of a request and matches to the longest matching server name. The server name is only used when the IP port combination in the listen directive matches more than one server. The default server parameter is a parameter of the listen directive, and defines which server block acts as the default server. The default server block serves a response when NGINX can't match the correct server block based on either the listen or server name directive values. Thank you for watching module three of the NGINX Core e-learning course.