Nginx 配置指令的执行顺序(二)

我们前面已经知道,当 set 指令用在 location 配置块中时,都是在当前请求的 rewrite 阶段运行的。事实上,在此上下文中,ngx_rewrite 模块中的几乎全部指令,都运行在 rewrite 阶段,包括 Nginx 变量漫谈(二) 中介绍过的 rewrite 指令。不过,值得一提的是,当这些指令使用在 server 配置块中时,则会运行在一个我们尚未提及的更早的处理阶段,server-rewrite 阶段。

Nginx 变量漫谈(二) 中介绍过的 ngx_set_misc 模块的 set_unescape_uri 指令同样也运行在 rewrite阶段。特别地,ngx_set_misc 模块的指令还可以和 ngx_rewrite 的指令混合在一起依次执行。我们来看这样的一个例子:

    location /test {        set $a "hello%20world";        set_unescape_uri $b $a;        set $c "$b!";         echo $c;    }

访问这个接口可以得到:

    $ curl ‘http://localhost:8080/test‘    hello world!

我们看到,set_unescape_uri 语句前后的 set 语句都按书写时的顺序一前一后地执行了。

为了进一步确认这一点,我们不妨再检查一下 Nginx 的“调试日志”(如果你还不清楚如何开启“调试日志”的话,可以参考 (一) 中的步骤):

    grep -E ‘http script (value|copy|set)‘ t/servroot/logs/error.log

过滤出来的调试日志信息如下所示:

    [debug] 11167#0: *1 http script value: "hello%20world"    [debug] 11167#0: *1 http script set $a    [debug] 11167#0: *1 http script value (post filter): "hello world"    [debug] 11167#0: *1 http script set $b    [debug] 11167#0: *1 http script copy: "!"    [debug] 11167#0: *1 http script set $c

开头的两行信息

    [debug] 11167#0: *1 http script value: "hello%20world"    [debug] 11167#0: *1 http script set $a

就对应我们的配置语句

    set $a "hello%20world";

而接下来的两行

    [debug] 11167#0: *1 http script value (post filter): "hello world"    [debug] 11167#0: *1 http script set $b

则对应配置语句

    set_unescape_uri $b $a;

我们看到第一行信息与 set 指令略有区别,多了 "(post filter)" 这个标记,而且最后显示出 URI 解码操作确实如我们期望的那样工作了,即 "hello%20world" 在这里被成功解码为 "hello world".

而最后两行调试信息

    [debug] 11167#0: *1 http script copy: "!"    [debug] 11167#0: *1 http script set $c

则对应最后一条 set 语句:

    set $c "$b!";

注意,因为这条指令在为 $c 变量赋值时使用了“变量插值”功能,所以第一行调试信息是以 http script copy 起始的,后面则是拼接到最终取值的字符串常量 "!".

把这些调试信息联系起来看,我们不难发现,这些配置指令的实际执行顺序是:

    set $a "hello%20world";    set_unescape_uri $b $a;    set $c "$b!";

这与它们在配置文件中的书写顺序完全一致。

我们在 Nginx 变量漫谈(七) 中初识了第三方模块 ngx_lua,它提供的 set_by_lua 配置指令也和ngx_set_misc 模块的指令一样,可以和 ngx_rewrite 模块的指令混合使用。set_by_lua 指令支持通过一小段用户 Lua 代码来计算出一个结果,然后赋给指定的 Nginx 变量。和 set 指令相似,set_by_lua 指令也有自动创建不存在的 Nginx 变量的功能。

下面我们就来看一个 set_by_lua 指令与 set 指令混合使用的例子:

    location /test {        set $a 32;        set $b 56;        set_by_lua $c "return ngx.var.a + ngx.var.b";        set $equation "$a + $b = $c";         echo $equation;    }

这里我们先将 $a 和 $b 变量分别初始化为 32 和 56,然后利用 set_by_lua 指令内联一行我们自己指定的 Lua 代码,计算出 Nginx 变量 $a 和 $b 的“代数和”(sum),并赋给变量 $c,接着利用“变量插值”功能,把变量 $a、 $b 和 $c 的值拼接成一个字符串形式的等式,赋予变量 $equation,最后再用 echo 指令输出 $equation 的值。

这个例子值得注意的地方是:首先,我们在 Lua 代码中是通过 ngx.var.VARIABLE 接口来读取 Nginx 变量$VARIABLE 的;其次,因为 Nginx 变量的值只有字符串这一种类型,所以在 Lua 代码里读取 ngx.var.a 和ngx.var.b 时得到的其实都是 Lua 字符串类型的值 "32" 和 "56";接着,我们对两个字符串作加法运算会触发 Lua 对加数进行自动类型转换(Lua 会把两个加数先转换为数值类型再求和);然后,我们在 Lua 代码中把最终结果通过 return 语句返回给外面的 Nginx 变量 $c;最后,ngx_lua 模块在给 $c 实际赋值之前,也会把return 语句返回的数值类型的结果,也就是 Lua 加法计算得出的“和”,自动转换为字符串(这同样是因为 Nginx 变量的值只能是字符串)。

这个例子的实际运行结果符合我们的期望:

    $ curl ‘http://localhost:8080/test‘    32 + 56 = 88

于是这验证了 set_by_lua 指令确实也可以和 set 这样的 ngx_rewrite 模块提供的指令混合在一起工作。

还有不少第三方模块,例如 Nginx 变量漫谈(八) 中介绍过的 ngx_array_var 以及后面即将接触到的用于加解密用户会话(session)的 ngx_encrypted_session,也都可以和 ngx_rewrite 模块的指令无缝混合工作。

标准 ngx_rewrite 模块的应用是如此广泛,所以能够和它的配置指令混合使用的第三方模块是幸运的。事实上,上面提到的这些第三方模块都采用了特殊的技术,将它们自己的配置指令“注入”到了 ngx_rewrite 模块的指令序列中(它们都借助了 Marcus Clyne 编写的第三方模块 ngx_devel_kit)。换句话说,更多常规的在 Nginx 的 rewrite 阶段注册和运行指令的第三方模块就没那么幸运了。这些“常规模块”的指令虽然也运行在rewrite 阶段,但其配置指令和 ngx_rewrite 模块(以及同一阶段内的其他模块)都是分开独立执行的。在运行时,不同模块的配置指令集之间的先后顺序一般是不确定的(严格来说,一般是由模块的加载顺序决定的,但也有例外的情况)。比如 A 和 B 两个模块都在 rewrite 阶段运行指令,于是要么是 A 模块的所有指令全部执行完再执行 B 模块的那些指令,要么就是反过来,把 B 的指令全部执行完,再去运行 A 的指令。除非模块的文档中有明确的交待,否则用户一般不应编写依赖于此种不确定顺序的配置。

时间: 2024-10-24 12:42:11

Nginx 配置指令的执行顺序(二)的相关文章

Nginx 配置指令的执行顺序(八)

前面我们详细讨论了 rewrite.access 和 content 这三个最为常见的 Nginx 请求处理阶段,在此过程中,也顺便介绍了运行在这三个阶段的众多 Nginx 模块及其配置指令.同时可以看到,请求处理阶段的划分直接影响到了配置指令的执行顺序,熟悉这些阶段对于正确配置不同的 Nginx 模块并实现它们彼此之间的协同工作是非常必要的.所以接下来我们接着讨论余下的那些阶段. 前面在 (一) 中提到,Nginx 处理请求的过程一共划分为 11 个阶段,按照执行顺序依次是 post-read

Nginx 配置指令的执行顺序(一)

大多数 Nginx 新手都会频繁遇到这样一个困惑,那就是当同一个 location 配置块使用了多个 Nginx 模块的配置指令时,这些指令的执行顺序很可能会跟它们的书写顺序大相径庭.于是许多人选择了“试错法”,然后他们的配置文件就时常被改得一片狼藉.这个系列的教程就旨在帮助读者逐步地理解这些配置指令背后的执行时间和先后顺序的奥秘. 现在就来看这样一个令人困惑的例子:     ? location /test {    ?     set $a 32;    ?     echo $a;    

Nginx 配置指令的执行顺序(十一)

紧跟在 post-access 阶段之后的是 try-files 阶段.这个阶段专门用于实现标准配置指令 try_files 的功能,并不支持 Nginx 模块注册处理程序.由于 try_files 指令在许多 FastCGI 应用的配置中都有用到,所以我们不妨在这里简单介绍一下. try_files 指令接受两个以上任意数量的参数,每个参数都指定了一个 URI. 这里假设配置了 N 个参数,则 Nginx 会在 try-files 阶段,依次把前 N-1 个参数映射为文件系统上的对象(文件或者

Nginx 配置指令的执行顺序(七)

来看一个 ngx_static 模块服务磁盘文件的例子.我们使用下面这个配置片段:     location / {        root /var/www/;    } 同时在本机的 /var/www/ 目录下创建两个文件,一个文件叫做 index.html,内容是一行文本 this is my home:另一个文件叫做 hello.html,内容是一行文本 hello world. 同时注意这两个文件的权限设置,确保它们都对运行 Nginx worker 进程的系统帐户可读. 现在来通过

NGINX openrestry(指令的执行顺序)

Nginx的指令的执行顺序: 一.post-read 二.server-rewrite ngx_rewrite模块的set指令和rewrite指令(前提在server里面配置时) 三.find-config 四.rewrite ngx_rewrite模块的set指令和rewrite指令(前提在location里面配置时) ngx_set_misc模块的set_unescape_uri指令 ngx_lua模块的set_by_lua指令 rewrite tail: ngx_headers_more模

Nginx 配置指令location 匹配符优先级和安全问题【转】

Nginx配置指令location匹配符优先级和安全问题 使用nginx 很久了,它的性能高,稳定性表现也很好,得到了很多人的认可.特别是它的配置,有点像写程序一样,每行命令结尾一个";"号,语句块用"{}"括起来.配制好,直接nginx -t 检查配制情况,配制成功,直接运行:service nginx reload.服务器没有任何宕机情况下,实现平稳修改配置.最近一直在做location 配置,遇到优先级别问题(如果配置不当可能存在安全隐患哦),以下是个人学习一

Nginx配置指令try_files

try_files指令是按顺序检测文件的存在性,并且返回第一个找到文件的内容,如果第一个找不到就会自动找第二个,依次查找.其实现的是内部跳转.以下举例说明: 案例1(跳转到变量): server {   listen 8000;   server_name 121.10.143.66;   root html;   index index.html index.php; location /abc { try_files /4.html /5.html @qwe;      --检测文件4.ht

转:Nginx配置指令location匹配符优先级和安全问题

转:http://www.jb51.net/article/47761.htm 使用nginx 很久了,它的性能高,稳定性表现也很好,得到了很多人的认可.特别是它的配置,有点像写程序一样,每行命令结尾一个";"号,语句块用"{}"括起来. 配制好,直接nginx -t 检查配制情况,配制成功,直接运行:service nginx reload .服务器没有任何宕机情况下,实现平稳修改配置 最近一直在做location 配置,遇到优先级别问题(如果配置不当可能存在安全

JFinal 配置类 方法执行顺序

1.public void configConstant(Constants me) 常量配置方法,一般 在里面 读取 配置文件 2.public void configRoute(Routes me) 配置路由,如下 me.add("/", IndexController.class, "/index"); // 第三个参数为该Controller的视图存放路径 me.add("/blog", BlogController.class); //