Nginx configuration command execution sequence (11)

The try-files phase follows the post-access phase. This stage is used to implement the standard configuration command try_files, and does not support Nginx module registration handler. The try_files command is useful in many FastCGI application configurations, so we may briefly introduce it here. Try_files indicates

The try-files phase follows the post-access phase. This stage is used to implement the standard configuration command try_files, and does not support Nginx module registration handler. The try_files command is useful in many FastCGI application configurations, so we may briefly introduce it here. Try_files indicates

The try-files phase follows the post-access phase. This stage is dedicated to implementing standardsConfigurationCommandTry_files does not support the Nginx module registration handler. Because try_filesCommandIn many FastCGI applicationsConfigurationSo we can briefly introduce it here.

Try_filesCommandTwo or more parameters are accepted. Each parameter specifies a URI.ConfigurationIn the try-files phase, Nginx maps the previous N-1 parameters to objects (files or directories) on the file system, and then checks whether these objects exist. Once Nginx discovers that a file system object exists, it will rewrite the URI of the current request to the parameter URI corresponding to the object in the try-files stage (but it does not contain the slash character at the end, does not cause "Internal redirection "). If the file system object corresponding to the previous N-1 parameters does not exist, the try-files phase immediately initiates an internal redirect to the last parameter (the nth parameter) the specified URI.

As you can see in (6) and (7), the static Resource Service Module maps the URI of the current request to the file system and uses the rootConfigurationCommandThe specified "document root directory" is mapped. For example, when the "document root directory" is/var/www/, the request URI/foo/bar will be mapped to the file/var/www/foo/bar, the request URI/foo/baz/is mapped to/var/www/foo/baz /. note how to distinguish between "directory" and "file" by using the slash character at the end of the URI. Try_files we are discussingConfigurationCommandUse the same rules to map each parameter URI to a file system object.

Let's take a look at the following example:

Root/var/www /;
Location/test {
Try_files/foo/bar // baz;
Echo "uri: $ uri ";
}
Location/foo {
Echo foo;
}
Location/bar /{
Echo bar;
}
Location/baz {
Echo baz;
}

Here we use rootCommandSet "document root directory"ConfigurationIt is/var/www/. If important data is stored in the/var/www/path in your system, you can replace it with any other path, however, this path must have at least the read permission on the system account that runs the Nginx worker process. We used try_files in location/test.ConfigurationCommandAnd provides three parameters:/foo,/bar/, And/baz.CommandWe can know that it will check whether the file system objects corresponding to the first two parameters/foo and/bar/exist in sequence in the try-files stage.

You may wish to start a group of experiments first. Assuming that the current/var/www/path is empty, the file/var/www/foo mapped to the first parameter does not exist. Similarly, the directory/var/www/bar/mapped by the second parameter does not exist. Therefore, Nginx will initiate an "Internal redirect" to the URI (that is,/baz) specified by the last parameter in the try-files phase ". The actual request results confirm this:

$ Curl localhost: 8080/test
Baz

Obviously, the request is eventually bound with location/baz,RunOutput the work of the baz string. The location/foo and location/bar/defined in the above example are not involved in the running process here, because for the previous N-1 parameters of try_files, Nginx will only check the file system, instead of goingRunURI and location match.

For the above request, Nginx will generate a "debug log" similar to the following ":

$ Grep trying logs/error. log
[Debug] 3869 #0: * 1 trying to use file: "/foo" "/var/www/foo"
[Debug] 3869 #0: * 1 trying to use dir: "/bar" "/var/www/bar"
[Debug] 3869 #0: * 1 trying to use file: "/baz" "/var/www/baz"

Through this information, we can clearly see what happened in the try-files phase: Nginx checks the file/var/www/foo and directory/var/www/bar in sequence, finally, the last parameter/baz is processed. the last piece of "debugging information" is easy to misunderstand and may mistakenly assume that Nginx maps the last parameter/baz to a file system object for inspection. This is not the case. When try_filesCommandWhen processing its last parameter, it is always directRun"Internal jump", regardless of whether the corresponding file system object exists.

Next, let's create an experiment: create a file named foo under/var/www, the content is hello world (note that you need write permission under the/var/www/directory ):

$ Echo 'Hello world'>/var/www/foo

Then request the/test interface:

$ Curl localhost: 8080/test
Uri:/foo

What happened here? Let's see, try_filesCommandThe first parameter/foo of can be mapped to the file/var/www/foo, while Nginx found that the file exists in the try-files phase, therefore, the URI of the current request is immediately rewritten to the value of this parameter, that is,/foo, and the subsequent parameters are not checked, but the subsequent request processing phase is directly run.

The "debug log" generated by the above request in the try-files stage is as follows:

$ Grep trying logs/error. log
[Debug] 4132 #0: * 1 trying to use file: "/foo" "/var/www/foo"

Obviously, in the try-files stage, Nginx only checks and processes the/foo parameter, and the subsequent parameters are all "short-circuited.

Similarly, assume that we delete the/var/www/foo file we just created, and create a subdirectory named bar under/var/www:

$ Mkdir/var/www/bar

The result of the request/test is similar:

$ Curl localhost: 8080/test
Uri:/bar

In this case, Nginx finds that the file corresponding to the first/foo parameter does not exist in the try-files stage, it will turn to check the file system object corresponding to the second parameter (here is the directory/var/www/bar /). Because this directory exists, Nginx will change the URI of the current request to the value of the second parameter, that is,/bar (note that the original parameter value is/bar /, however, try_files automatically removes the trailing slash characters ).

The "debug log" generated by this group of labs is as follows:

$ Grep trying logs/error. log
[Debug] 4223 #0: * 1 trying to use file: "/foo" "/var/www/foo"
[Debug] 4223 #0: * 1 trying to use dir: "/bar" "/var/www/bar"

We can see that try_filesCommandOnly the first two parameters are checked and processed here.

Through the above groups of experiments, it is not difficult to see, try_filesCommandEssentially, only the URI of the current request is rewritten with conditions. The "condition" mentioned here is actually whether the object in the file system exists. When none of the conditions are met, it will initiate a specified internal jump unconditionally ". Of course, in addition to unconditionally initiating an "Internal redirect", try_filesCommandYou can also directly return the HTTP Error Page of the specified status code, for example:

Try_files/foo/bar/= 404;

This lineConfigurationIf the file system objects corresponding to the/foo and/bar/parameters do Not exist, the 404 Not Found error page is returned directly. Note how to use the equal sign prefix to identify the HTTP status code.