openresty开发系列35--openresty执行流程之5内容content阶段

openresty开发系列35--openresty执行流程之5内容content阶段

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

语法：content_by_lua <lua-script-str>
默认值：无
上下文：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 阶段。

考虑下面这个有问题的例子：

location /content1 {
 echo "hello ";
 content_by_lua 'ngx.say("world")';
}

访问 http://10.11.0.215/content1 输出 world

# 调换顺序
location /content1 {
 
 content_by_lua 'ngx.say("world")';
 echo "hello ";

}

访问 http://10.11.0.215/content1 输出 hello

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

访问输出 world

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

location /content1 {
    echo hello;
    echo world;
}

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

location /content1 {
  content_by_lua 'ngx.say("hello")';
  content_by_lua 'ngx.say("world")';
}

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

正确写法：
location /content1 {
    content_by_lua 'ngx.say("hello") ngx.say("world")';
}

----------------------------------------------

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

静态资源服务模块

1) ngx_index
2) ngx_autoindex
3) ngx_static

location /content {
    
}

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 这样的，
 例如：

location / {
    root   html;
    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 模块在找到文件时的“内部跳转”行为，看下面的例子

location / {
    root   html;
    index  index.html;
}

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

输出 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 错误日志中留下了类似这一行信息：

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

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

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

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

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

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

---------------------

在下面例子

location / {
    root html;
}

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

访问http://10.11.0.215/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 等响应头。