Einführung in die Nginx-Phasen

Wenn Sie die Rewrite-Anweisung an der Position platzieren, gelangen Sie in die Rewrite-Phase, die sich an der Position befindet In der URI-Umschreibungsphase können die Umschreibungsanweisungen auch mehrmals ausgeführt werden.

Die Umschreibungsanweisungen umfassen die Set-Anweisung und die Rewrite-Anweisung von HttpRewriteModule, die set_by_lua-Anweisung von HttpLuaModule und die set_unescape_uri-Anweisung des ngx_set_misc-Moduls Und fast alle HttpRewriteModule Die Anweisungen gehören alle zur Rewrite-Phase.

Lassen Sie uns an dieser Stelle über eine Frage nachdenken: Können diese Anweisungen an derselben Stelle koexistieren, da sie in dieser Phase neu geschrieben werden können?

Beispiel 1:
Denken Sie über die Ausgabe des folgenden Beispiels nach. Was ist das Ergebnis?

 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;
    }

Wenn wir auf http://localhost/test zugreifen, ist die Ausgabe 32 + 56 = 88, was unseren Erwartungen entsprechen sollte.

Dies beweist jedoch nicht, dass alle Anweisungen verschiedener Module, die zu denselben Phasen gehören, in der richtigen Reihenfolge ausgeführt werden müssen, wenn sie in einer Phase koexistieren. Tatsächlich verwenden die oben genannten Module von Drittanbietern alle spezielle Techniken, um ihre eigenen Konfigurationsanweisungen in die Befehlssequenz von HttpRewriteModule zu „einzufügen“ (sie alle verwenden das von Marcus Clyne geschriebene Modul ngx_devel_kit eines Drittanbieters). Mit anderen Worten: Konventionelleres Umschreiben in Nginx Module von Drittanbietern, die die Registrierung durchführen und Anweisungen ausführen, haben nicht so viel Glück. Obwohl die Anweisungen dieser „regulären Module“ auch in der Rewrite-Phase ausgeführt werden, werden ihre Konfigurationsanweisungen und HttpRewriteModule (und andere Module in derselben Phase) unabhängig voneinander ausgeführt. Zur Laufzeit ist die Reihenfolge zwischen den Konfigurationsbefehlssätzen verschiedener Module im Allgemeinen ungewiss (streng genommen wird sie im Allgemeinen durch die Ladereihenfolge der Module bestimmt, es gibt jedoch Ausnahmen). Beispielsweise führen beide Module A und B Anweisungen in der Umschreibephase aus, sodass entweder alle Anweisungen von Modul A ausgeführt werden, bevor die Anweisungen von Modul B ausgeführt werden, oder umgekehrt, alle Anweisungen von Modul B ausgeführt werden und dann A ausgeführt wird Anweisungen ausgeführt. Sofern in der Dokumentation des Moduls nicht ausdrücklich angegeben, sollten Benutzer im Allgemeinen keine Konfigurationen schreiben, die auf dieser unbestimmten Reihenfolge basieren. Es gibt auch viele Module von Drittanbietern, ngx_array_var Und ngx_encrypted_session, das zum Ver- und Entschlüsseln von Benutzersitzungen verwendet wird, kann auch nahtlos mit den Anweisungen von HttpRewriteModule zusammenarbeiten. Das Standard-HttpRewriteModule ist so weit verbreitet, dass Module von Drittanbietern, die mit seinen Konfigurationsanweisungen gemischt werden können, von Vorteil sind. Anweisungen, die nicht mit HttpRewriteModule gemischt werden können, sollten bei der tatsächlichen Verwendung beachtet werden. Ihre Ausgabe ist undefiniert, was nichts mit ihrer Reihenfolge in der Konfigurationsdatei zu tun hat.

Fazit: Anweisungen mit Bereichen in verschiedenen Modulen derselben Phase. Wenn besondere Kompatibilität zwischen Modulen hergestellt wird, werden sie nacheinander in der Reihenfolge ausgeführt, in der die Anweisungen in der Konfigurationsdatei erscheinen

Beispiel 2:
Überlegen Sie, wie die Ausgabe unten aussieht?

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;
    }