Execution order of Nginx configuration directives (vii)

See an ngx_static example of a module service disk file. We use the following configuration fragment:

Location/{
root/var/www/;
}

At the same time, in the local /var/www/ directory to create two files, a file index.html is called, the content is a line of text, this is my home another file hello.html is called, the content is a line hello world of text. Also note the permissions settings for these two files to make sure that they are all running on Nginx worker The system account of the process is readable.

Now to request the URI for these two files over the HTTP protocol:

$ Curl ' http://localhost:8080/index.html '
This is my home

$ Curl ' http://localhost:8080/hello.html '
Hello World

We see that the contents of the two disk files created previously were output separately.

It may be useful to analyze what happened here: in the absence of the location / module instructions running in the content stage, so there is no module to register the location "Content processing program", processing power automatically fell to the content stage "bottom" of the 3 static resource Services Module. The first run of the Ngx_index and Ngx_autoindex modules see the URI of the current request, /index.html and /hello.html , not to the / end, so direct waiver, the processing right to the last running ngx_static module. The ngx_static module assigns the request URI and map to the file system path according to the "document Root" specified by the root instruction, /index.html /hello.html /var/www/index.html and /var/www/hello.html , after confirming the existence of the two files, outputs their contents as the response body, respectively. , and automatically sets Content-Type , Content-Length as well Last-Modified as the response headers.

In order to confirm that the ngx_static module is actually running, you can enable the Nginx "debug Log" described in (i), and then request /index.html this interface again. In this case, you can see debugging information similar to the following line in the Nginx error log file:

[Debug] 3033#0: * http static Fd:8

This line of information ngx_static is generated by the module, meaning "the descriptor of the static file being output is a number 8 ". Of course, the specific file descriptor number will change frequently, this is just a typical output of my machine. It is worth mentioning that the ability to generate this line of debugging information is also the standard module ngx_gzip_static, but it is not enabled by default, will be introduced specifically to this module.

Note that the root configuration directive used in the above example only acts as a declaration of the "document Root", not that it opens the ngx_static module. The ngx_static module is always on, but whether the wheel gets it to run depends content on whether the modules that run before it are "abstained". To further confirm this, take a look at the following blank location definition:

Location/{
}

Because the root command is not configured, Nginx automatically calculates a default "document Root" when accessing this interface. The default value is to take a subdirectory under the so-called "configuration prefix" (Configure prefix) path html/ . For example, suppose the "configuration prefix" is /foo/bah/ , then the default "document Root" is /foo/bar/html/ .

So what is the "configuration prefix" to decide? By default, it is the root of the Nginx installation (or the path value of the option that is passed to the script when Nginx is constructed ./configure --prefix ). If Nginx is installed /usr/local/nginx/ , the "configuration prefix" is the /usr/local/nginx/ default "document Root" /usr/local/nginx/html/ . However, we can also --prefix temporarily specify our own "configuration prefix" path with the command-line option when the Nginx is started. Let's say the command we use when we start Nginx is

Nginx-p/home/agentzh/test/

For this server instance, its "configuration prefix" is /home/agentzh/test/ , and the default "document root directory" is /home/agentzh/test/html/ . The "configuration prefix" not only determines the default "document Root", but also determines how many of the relative path values in the Nginx configuration file are interpreted as absolute paths, and we will see many examples that need to be referenced to the "configuration prefix".

There is a very handy way to get the path to the current document root directory, which is to request a resource name for a file that does not exist, for example:

$ Curl ' http://localhost:8080/blah-blah.txt '
<body bgcolor= "White" >
<center></body>
We will naturally get the 404 error page. Now look at the Nginx error log file, you should see a line similar to the following error message:
[ERROR] 9364#0: * Open () "/home/agentzh/test/html/blah-blah.txt" failed (2:no such file or directory)
This error message is ngx_static printed by the module because it does not find a file named on the corresponding path of the file system blah-blah.txt . Because this error message contains an ngx_static absolute path to the file you are trying to open, it is not difficult to see from this path that the current "document Root" is /home/agentzh/test/html/ .
Many beginners will take it for granted that 404 a mistake location does not exist, but the above example shows that even if there is a location successful match, it is possible to return 404 the error page. Because 404 the error page is determined by whether the abstract "resource" exists, rather than whether a specific location one exists.
A common mistake for beginners is to forget content the module directives in the configuration phase, which they do not expect to use content static resource services that run at the default stage, for example:
     location /auth {
          access_by_lua  ' 
             -- a  lot of lua code omitted here ... 
          '; 
     } 
 Obviously, this   /auth    interface defines only    access    Stage configuration directives, or  access_by_lua, do not define any    content    configuration directives for the stage. So when we ask for   /auth    Interface, the Lua code in &NBSP,  access    phase executes as expected, and then    content The static file services of the    phase will automatically take effect until    ngx_static    module to find the file system named    Auth    files. Frequently,  404    Error pages are thrown, unless there is a good chance that there is a file called    auth    on the corresponding path. So, one experience is that when you encounter an unexpected  ,  404    Error and do not involve a static file service, you should first check for the corresponding    location    &NBSP is properly configured in the configuration block, and module directives for  content    stages, such as  content_by_lua,  echo , and  proxy_pass   Stuff. Of course, Nginx  error.log    files often provide answers to unexpected questions, such as my   for the above example;  error.log    This error message is in the following: 
[ERROR] 9364#0: * Open () "/home/agentzh/test/html/auth" failed (2:no such file or directory)
Execution order of Nginx configuration directives (vii)