nginx phases introduction

If the rewrite instruction is placed in the location, then it enters the rewrite phase. This stage is the location-level uri rewrite stage, and the rewrite instruction may also be executed multiple times;

Rewrite instructions include the set instruction and rewrite instruction of HttpRewriteModule, the set_by_lua instruction of HttpLuaModule, and the set_unescape_uri instruction of the ngx_set_misc module. In addition, almost all instructions of HttpRewriteModule belong to the rewrite stage.

At this point, let’s think about a question: Since the instructions can be rewritten in this phase without using different modules, can these instructions coexist in the same location? If so, what is their execution order?

Example 1:
Think about the output of the following example?

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

When we access http://localhost/test, the output result is 32 + 56 = 88, which should be consistent with our expectations.

But this does not prove that all the instructions of different modules belonging to the same phases must be executed in order when they coexist in a phase. In fact, the third-party modules mentioned above all use special techniques to "inject" their own configuration instructions into the instruction sequence of HttpRewriteModule (they all use the third-party module ngx_devel_kit written by Marcus Clyne). In other words, more conventional rewrite in Nginx Third-party modules that stage registration and run instructions are not so lucky. Although the instructions of these "regular modules" also run in the rewrite stage, their configuration instructions and HttpRewriteModule (and other modules in the same stage) are executed independently. At runtime, the order between the configuration instruction sets of different modules is generally uncertain (strictly speaking, it is generally determined by the loading order of the modules, but there are exceptions). For example, both modules A and B run instructions in the rewrite stage, so either all instructions of module A are executed before executing those instructions of module B, or the other way around, all instructions of module B are executed, and then A is executed. instructions. Unless explicitly stated in the module's documentation, users should generally not write configurations that rely on this indeterminate order. There are also many third-party modules, ngx_array_var And ngx_encrypted_session, which is used to encrypt and decrypt user sessions, can also work seamlessly with the instructions of HttpRewriteModule. The standard HttpRewriteModule is so widely used that third-party modules that can be mixed with its configuration directives are fortunate. Instructions that cannot be mixed with HttpRewriteModule should be noted during actual use. Its output is undefined, which has nothing to do with their order in the configuration file.

Conclusion: If the instructions of different modules with the same scope in the same phase are specially compatible with each other, they will be executed sequentially in the order in which the instructions appear in the configuration file.

Example 2:
Think about the following output What?

location /test {
        set $value dog;
        more_set_input_headers "X-Species: $value";
        set $value cat;
        echo "X-Species: $http_x_species";
    }

说明：第三方模块 ngx_headers_more 提供了一系列配置指令，用于操纵当前请求的请求头和响应头。其中有一条名叫 more_set_input_headers 的指令可以在 rewrite 阶段改写指定的请求头（或者在请求头不存在时自动创建）。该指令的文档中有这么一行标记 phase： rewrite tail,是说这条指令总是运行在 rewrite 阶段的末尾。显然，写在 more_set_input_headers 指令之后的 set $value cat 语句却先执行了。也就是说属于HttpRewriteModule的set指令先执行完了，才执行ngx_header_more 的set_input_headers指令。
结论：即使运行在同一个请求处理阶段，分属不同模块的配置指令也可能会分开独立运行（除非像 ngx_set_misc 等模块那样针对 ngx_rewrite 模块提供特殊支持）。换句话说，在单个请求处理阶段内部，一般也会以 Nginx 模块为单位进一步地划分出内部子阶段。下面的例子3同例子2：

例子3：

location /test {
         set $a 1;
         rewrite_by_lua "ngx.var.a = ngx.var.a + 1";
         set $a 56;    
         echo $a;
     }

说明：HttpLuaModule的rewrite_by_lua 指令也是处在 rewrite tail phase，它也会在rewrite 阶段的末尾执行。因此HttpRewriteModule的所有set执行完后，才执行它。
显然，rewrite_by_lua 指令的行为不同于我们前面在 （二） 中介绍过的 set_by_lua 指令。
小伙伴们可能要问，既然 more_set_input_headers 和 rewrite_by_lua 指令都运行在 rewrite 阶段的末尾，那么它们之间的先后顺序又是怎样的呢？答案是：不一定。我们应当避免写出依赖它们二者间顺序的配置。

结论：作用域在同一个phase的不同modules的指令，如果没有做特殊兼容处理，则它们指令的执行顺序与指令在配置中出现的顺序无关，结果具有不确定性

    location /hello {
        allow 127.0.0.1;
        deny all; 
        echo "hello world";
    }

    location /hello {
        deny all; 
        allow 127.0.0.1;
        echo "hello world";
    }

try_files $uri $uri/ /index.php?q=$uri&$args

 location /test {
          set $a 123;
          set $b 456;
          echo $b;
          content_by_lua '
             ngx.say(ngx.var.a)
           ';
    }

 location /test_echo {
          content_by_lua '
             ngx.say(ngx.var.a)
           ';
          set $a 123;
          set $b 456;
    }