内容content 阶段

---init阶段---重写赋值---重写rewrite---access

content 阶段属于一个比较靠后的处理阶段，运行在先前介绍过的 rewrite 和 access 这两个阶段之后。 当和 rewrite、access 阶段的指令一起使用时，这个阶段的指令总是最后运行，例如：

location /content {
    # 重写阶段
    set $age 1;
    rewrite_by_lua "ngx.var.age = ngx.var.age + 1";

    # 访问阶段
    deny 127.0.0.1;
    access_by_lua "ngx.var.age = ngx.var.age * 2";

    # 内容阶段
    echo "age = $age";
}

启动nginx ，访问 输出 age = 4

改变它们的书写顺序，也不会影响到执行顺序。其中， set 指令来自 ngx_rewrite 模块，运行于 rewrite 阶段；

而 rewrite_by_lua 指令来自 ngx_lua 模块，运行于 rewrite 阶段的末尾；

接下来，deny 指令来自 ngx_access 模块，运行于 access 阶段；

再下来，access_by_lua 指令同样来自 ngx_lua 模块，运行于 access 阶段的末尾；

最后，echo 指令则来自 ngx_echo 模块，运行在 content 阶段

一）content_by_lua

语法：

默认值：无

上下文：location, location if

说明：行为类似与一个“content handler”，给每个请求执行定义于lua-script-str中的lua code。 每一个 location 只能有一个“内容处理程序”，因此，当在 location 中同时使用多个模块的 content 阶段指令时， 只有其中一个模块能成功注册“内容处理程序”。例如这个指令和proxy_pass指令不能同时使用在相同的location中

例中的 set 指令和 rewrite_by_lua 指令同处于 rewrite 阶段， 而 deny 指令和 access_by_lua 指令则同处于 access 阶段。 但不幸的是echo指令，不能同时content_by_lua处于 content 阶段。

这里，ngx_echo 模块的 echo 指令和 ngx_lua 模块的 content_by_lua 指令同处 content 阶段， 但是只有其中一个模块能注册和运行这个 location 的“内容处理程序”：

访问输出 world

输出了后面的 content_by_lua 指令；而 echo 指令则完全没有运行。 例中的 echo 语句和 content_by_lua 语句交换顺序，则输出就会变成 hello。 所以我们应当避免在同一个 location 中使用多个模块的 content 阶段指令。

这里使用多条 echo 指令是没问题的，因为它们同属 ngx_echo 模块，而且 ngx_echo模块规定和实现了它们之间的 执行顺序。并非所有模块的指令都支持在同一个 location 中被使用多次，例如 content_by_lua 就只能使用一次， 所以下面这个例子是错误的：

报错nginx: [emerg] "content_by_lua" directive is duplicate

正确写法：

二）如果一个 location 中未使用任何 content 阶段的指令，会如何处理？

静态资源服务模块

  • 1) ngx_index

  • 2) ngx_autoindex

  • 3) ngx_static

nginx会把当前请求的 URI 映射到文件系统的静态资源服务模块。 当存在“内容处理程序”时，这些静态资源服务模块并不会起作用；反之，请求的处理权就会自动落到这些模块上。

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

下面就来逐一介绍一下这三个模块

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

而 ngx_static 模块则刚好相反，直接忽略那些 URI 以 / 结尾的请求。

以 / 结尾的请求 ===》 ngx_index 和 ngx_autoindex 模块 进行处理

不以 / 结尾的请求 ===》 ngx_static 进行处理

1） ngx_index 模块

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

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

内部跳转：rewrite last 内容跳转

验证 ngx_index 模块在找到文件时的“内部跳转”行为，看下面的例子

输出 a = 32

为什么输出不是 index.html 文件的内容？首先对于用户的原始请求 GET /，Nginx 匹配出 location / 来处理它， 然后 content 阶段的 ngx_index 模块在 html 下找到了 index.html，于是立即发起一个到 /index.html 位置的“内部跳转”。在重新为 /index.html 这个新位置匹配 location 配置块时， location /index.html 的优先级要高于 location /，因为 location 块按照 URI 前缀来匹配时遵循所谓的 “最长子串匹配语义”。这样，在进入 location /index.html 配置块之后，又重新开始执行 rewrite 、access、 以及 content 等阶段。最终输出 a = 32

如果此时把 /html/index.html 文件删除，再访问 / 又会发生什么事情呢？ 答案是返回 403 Forbidden 出错页。

为什么呢？因为 ngx_index 模块找不到 index 指令指定的文件index.html， 接着把处理权转给 content 阶段的后续模块，而后续的模块也都无法处理这个请求， 于是 Nginx 只好放弃，输出了错误页，并且在 Nginx 错误日志中留下了类似这一行信息：

2) ngx_autoindex 模块

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

此时仍然保持文件系统中的 /html/index.html 文件不存在。我们再访问 / 位置时，就会得到目录下的文件列表

3）ngx_static 模块

在 content 阶段默认“垫底”的最后一个模块便是极为常用的 ngx_static 模块。

这个模块主要实现服务静态文件的功能。比方说，一个网站的静态资源，包括静态 .html 文件、静态 .css 文件、 静态 .js 文件、以及静态图片文件等等，全部可以通过这个模块对外服务。

前面介绍的 ngx_index 模块虽然可以在指定的首页文件存在时发起“内部跳转”，但真正把相应的首页文件服务出去 （即把该文件的内容作为响应体数据输出，并设置相应的响应头），还是得靠这个 ngx_static 模块来完成。

在下面例子

在html目录下创建hello.html文件

访问http://127.0.0.1/hello.html

不妨来分析一下这里发生的事情：location / 中没有使用运行在 content 阶段的模块指令， 于是也就没有模块注册这个 location 的“内容处理程序”，处理权便自动落到了在 content 阶段“垫底”的 那 3 个静态资源服务模块。

  • a）首先运行的 ngx_index 和 ngx_autoindex 模块先后看到当前请求的 URI，/hello.html，并不以 / 结尾， 于是直接弃权，

  • b）将处理权转给了最后运行的 ngx_static 模块。ngx_static 模块根据 root 指令指定的“文档根目录” （document root），分别将请求 /hello.html 映射为文件系统路径 /html/hello.html，在确认这个文件存在后， 将它们的内容分别作为响应体输出，并自动设置 Content-Type、Content-Length 以及 Last-Modified 等响应头。

Previous访问阶段Next内容响应阶段

Last updated

Was this helpful?