在一个 location 中使用 content 阶段指令时，通常情况下就是对应的 Nginx 模块注册该 location 中的“内容处理程序”。那么当一个 location 中未使用任何 content 阶段的指令，即没有模块注册“内容处理程序”时，content 阶段会发生什么事情呢？谁又来担负起生成内容和输出响应的重担呢？答案就是那些把当前请求的 URI 映射到文件系统的静态资源服务模块。当存在“内容处理程序”时，这些静态资源服务模块并不会起作用；反之，请求的处理权就会自动落到这些模块上。

Nginx 一般会在 content 阶段安排三个这样的静态资源服务模块（除非你的 Nginx 在构造时显式禁用了这三个模块中的一个或者多个，又或者启用了这种类型的其他模块）。按照它们在 content 阶段的运行顺序，依次是 ngx_index 模块，ngx_autoindex 模块，以及 ngx_static 模块。下面就来逐一介绍一下这三个模块。

ngx_index 和 ngx_autoindex 模块都只会作用于那些 URI 以 / 结尾的请求，例如请求 GET /cats/，而对于不以 / 结尾的请求则会直接忽略，同时把处理权移交给 content 阶段的下一个模块。而 ngx_static 模块则刚好相反，直接忽略那些 URI 以 / 结尾的请求。

ngx_index 模块主要用于在文件系统目录中自动查找指定的首页文件，类似 index.html 和 index.htm这样的，例如：

    location / {
        root /var/www/;
        index index.htm index.html;
    }

这样，当用户请求 / 地址时，Nginx 就会自动在 root 配置指令指定的文件系统目录下依次寻找 index.htm 和index.html 这两个文件。如果 index.htm 文件存在，则直接发起“内部跳转”到 /index.htm 这个新的地址；而如果 index.htm 文件不存在，则继续检查 index.html 是否存在。如果存在，同样发起“内部跳转”到/index.html；如果 index.html 文件仍然不存在，则放弃处理权给 content 阶段的下一个模块。

我们前面已经在 Nginx 变量漫谈（二） 中提到， echo_exec 指令和 rewrite 指令可以发起“内部跳转”。这种跳转会自动修改当前请求的 URI，并且重新匹配与之对应的 location 配置块，再重新执行rewrite、access、content 等处理阶段。因为是“内部跳转”，所以有别于 HTTP 协议中定义的基于 302 和 301 响应的“外部跳转”，最终用户的浏览器的地址栏也不会发生变化，依然是原来的 URI 位置。而ngx_index 模块一旦找到了 index 指令中列举的文件之后，就会发起这样的“内部跳转”，仿佛用户是直接请求的这个文件所对应的 URI 一样。

为了进一步确认 ngx_index 模块在找到文件时的“内部跳转”行为，我们不妨设计下面这个小例子：

    location / {
        root /var/www/;
        index index.html;
    }
 
    location /index.html {
        set $a 32;
        echo "a = $a";
    }

此时我们在本机的 /var/www/ 目录下创建一个空白的 index.html 文件，并确保该文件的权限设置对于运行 Nginx worker 进程的帐户可读。然后我们来请求一下根位置（/）：

    $ curl 'http://localhost:8080/'
    a = 32

这里发生了什么？为什么输出不是 index.html 文件的内容（即空白）？首先对于用户的原始请求 GET /，Nginx 匹配出 location / 来处理它，然后 content 阶段的 ngx_index 模块在 /var/www/ 下找到了index.html，于是立即发起一个到 /index.html 位置的“内部跳转”。

到这里，相信大家都不会有问题。接下来有趣的事情发生了！在重新为 /index.html 这个新位置匹配location 配置块时，location /index.html 的优先级要高于 location /，因为 location 块按照 URI 前缀来匹配时遵循所谓的“最长子串匹配语义”。这样，在进入 location /index.html 配置块之后，又重新开始执行 rewrite 、access、以及 content 等阶段。最终输出 a = 32 自然也就在情理之中了。

我们接着研究上面这个例子。如果此时把 /var/www/index.html 文件删除，再访问 / 又会发生什么事情呢？答案是返回 403 Forbidden 出错页。为什么呢？因为 ngx_index 模块找不到 index 指令指定的文件（在这里就是 index.html），接着把处理权转给 content 阶段的后续模块，而后续的模块也都无法处理这个请求，于是 Nginx 只好放弃，输出了错误页，并且在 Nginx 错误日志中留下了类似这一行信息：

    [error] 28789#0: *1 directory index of "/var/www/" is forbidden

所谓 directory index 便是生成“目录索引”的意思，典型的方式就是生成一个网页，上面列举出 /var/www/目录下的所有文件和子目录。而运行在 ngx_index 模块之后的 ngx_autoindex 模块就可以用于自动生成这样的“目录索引”网页。我们来把上例修改一下：

    location / {
        root /var/www/;
        index index.html;
        autoindex on;
    }

此时仍然保持文件系统中的 /var/www/index.html 文件不存在。我们再访问 / 位置时，就会得到一张漂亮的网页：

    $ curl 'http://localhost:8080/'
    <html>
    <head><title>Index of /</title></head>
    <body bgcolor="white">
    <h1>Index of /</h1><hr><pre><a href="../">../</a>
    <a href="cgi-bin/">cgi-bin/</a>  08-Mar-2010 19:36   -
    <a href="error/">error/</a>      08-Mar-2010 19:36   -
    <a href="htdocs/">htdocs/</a>    05-Apr-2010 03:55   -
    <a href="icons/">icons/</a>      08-Mar-2010 19:36   -
    </pre><hr></body>
    </html>

生成的 HTML 源码显示，我本机的 /var/www/ 目录下还有 cgi-bin/, error/, htdocs/, 以及 icons/ 这几个子目录。在你的系统中尝试上面的例子，输出很可能会不太一样。

值得一提的是，当你的文件系统中存在 /var/www/index.html 时，优先运行的 ngx_index 模块就会发起“内部跳转”，根本轮不到 ngx_autoindex 执行。感兴趣的读者可以自己测试一下。

在 content 阶段默认“垫底”的最后一个模块便是极为常用的 ngx_static 模块。这个模块主要实现服务静态文件的功能。比方说，一个网站的静态资源，包括静态 .html 文件、静态 .css 文件、静态 .js 文件、以及静态图片文件等等，全部可以通过这个模块对外服务。前面介绍的 ngx_index 模块虽然可以在指定的首页文件存在时发起“内部跳转”，但真正把相应的首页文件服务出去（即把该文件的内容作为响应体数据输出，并设置相应的响应头），还是得靠这个 ngx_static 模块来完成。

Nginx 配置指令的执行顺序的更多相关文章

  1. Nginx 配置指令的执行顺序（八）

    前面我们详细讨论了 rewrite.access 和 content 这三个最为常见的 Nginx 请求处理阶段,在此过程中,也顺便介绍了运行在这三个阶段的众多 Nginx 模块及其配置指令.同时可以 ...

  2. Nginx 配置指令的执行顺序（五）

    Nginx 的 content 阶段是所有请求处理阶段中最为重要的一个,因为运行在这个阶段的配置指令一般都肩负着生成“内容”(content)并输出 HTTP 响应的使命.正因为其重要性,这个阶段的配 ...

  3. Nginx 配置指令的执行顺序（一）

    大多数 Nginx 新手都会频繁遇到这样一个困惑,那就是当同一个 location 配置块使用了多个 Nginx 模块的配置指令时,这些指令的执行顺序很可能会跟它们的书写顺序大相径庭.于是许多人选择了 ...

  4. Nginx配置指令的执行顺序

    rewrite阶段 rewrite阶段是一个比较早的请求处理阶段,这个阶段的配置指令一般用来对当前请求进行各种修改(比如对URI和URL参数进行改写),或者创建并初始化一系列后续处理阶段可能需要的Ng ...

  5. Nginx 配置指令的执行顺序（十）

    运行在 post-rewrite 阶段之后的是所谓的 preaccess 阶段.该阶段在 access 阶段之前执行,故名preaccess. 标准模块 ngx_limit_req 和 ngx_lim ...

  6. Nginx 配置指令的执行顺序（六）

    前面我们在 (五) 中提到,在一个 location 中使用 content 阶段指令时,通常情况下就是对应的 Nginx 模块注册该 location 中的“内容处理程序”.那么当一个 locati ...

  7. Nginx 配置指令的执行顺序（三）

    如前文所述,除非像 ngx_set_misc 模块那样使用特殊技术,其他模块的配置指令即使是在 rewrite 阶段运行,也不能和 ngx_rewrite 模块的指令混合使用.不妨来看几个这样的例子. ...

  8. Nginx 配置指令的执行顺序（二）

    我们前面已经知道,当 set 指令用在 location 配置块中时,都是在当前请求的 rewrite 阶段运行的.事实上,在此上下文中,ngx_rewrite 模块中的几乎全部指令,都运行在 rew ...

  9. Nginx 配置指令的执行顺序（十一）

    紧跟在 post-access 阶段之后的是 try-files 阶段.这个阶段专门用于实现标准配置指令 try_files 的功能,并不支持 Nginx 模块注册处理程序.由于 try_files  ...

随机推荐

  1. What makes grep consider a file to be binary?

    grep -a worked for me: $ grep --help [...] -a, --text equivalent to --binary-files=text

  2. luogu P2776 [SDOI2007]小组队列

    题目背景 嘛,这道非常简单的给大家提供信心的省选题洛谷居然没有! 这么简单的题怎么可以没有! 给大家提升士气是义不容辞的责任! 所以我就来补一下啦.. 值得一提的是,标程是我自己做的.. 很渣,因为数 ...

  3. 【gcc】warning: control reaches end of non-void function

    用gcc编译一个C程序的时候出现这样的警告: warning: control reaches end of non-void function 它的意思是:控制到达非void函数的结尾.就是说你的一 ...

  4. [ZZ]机器学习的入门

    转载自: http://www.cnblogs.com/mq0036/p/7131678.html 本篇虽不是这一个月的流水账,但是基本按照下面的思路对着一个月做了一次总结: 什么是机器学习? 机器学 ...

  5. Tomcat部署多个应用时日志文件路径相同引起的问题

    今天给客户部署新系统,一个 前台应用,一个后台应用,由于用的是同一个架子,日志文件路径也没改,所以两个应用的日志文件是同一个文件,这样应用运行时,就会出现只能访问一个应用的情况,如果两个应用同时访问, ...

  6. linux的chown命令

    chown将指定文件的拥有者改为指定的用户或组,用户可以是用户名或者用户ID:组可以是组名或者组ID:文件是以空格分开的要改变权限的文件列表,支持通配符.系统管理员经常使用chown命令,在将文件拷贝 ...

  7. 【重点突破】—— 百度地图在React单页面应用中的使用

    前言:百度地图是网页中使用地图的常用第三方工具,这里结合React项目中学到的应用场景总结一些使用要点. 一.在网页中嵌入百度地图 搜百度地图开放平台,注册百度开发者账号 控制台:查看应用.创建应用( ...

  8. 用PHP上传文件时$_FILES中error返回值详解

    用PHP上传文件时,我们会用程序去监听浏览器发送过来的文件信息,首先会通 过$_FILES[fieldName]['error']的不同数值来判断此欲上传的文件状态是否正常.$_FILES[field ...

  9. 10. 修改端口号【从零开始学Spring Boot】

    转载:http://blog.csdn.net/linxingliang/article/details/51637017 spring boot 默认端口是8080,如果想要进行更改的话,只需要修改 ...

  10. Angular 学习笔记——$rounte

    <!DOCTYPE HTML> <html ng-app="myApp"> <head> <meta http-equiv="C ...