Verschachtelte Ortsblöcke in der NGINX-Konfiguration

NGINXKonfiguration

Wenn es Ihnen so geht wie mir, haben Sie schon oft in der NGINX-Dokumentation nachgeschaut (nur so zum Spaß) und Folgendes gefunden:

location blocks can be nested, with some exceptions mentioned below

Und Sie haben sich gedacht: "Wow, das ist so unspezifisch. Was bedeutet das Verschachteln von Ortsblöcken eigentlich? Warum sollte ich das tun?"

Nun, ich habe die nginx-Konfiguration eingehend untersucht und kann Ihnen einige Einblicke in meine Erkenntnisse geben. Sie können jederzeit einen Blick in die NGINX-Dokumentation werfen, wenn Sie eine Auffrischung benötigen, wie NGINX-Konfigurationsblöcke funktionieren.

Standorte

Es können vier Arten von NGINX-Config-Speicherorten definiert werden, die ich wie folgt bezeichnen möchte:

Exact-match (=-Typ) Speicherorte
Einfache Config-Speicherorte
Strong prefix config locations
Regex-Konfigurations-Speicherorte

Die ersten drei ähneln sich insofern, als dass sie alle NGINX-Konfigurationsdateien vom Präfix-Typ sind. Sie müssen alle mit dem Anfang des angeforderten Uniform Resource Identifier (URI) übereinstimmen. Der Speicherort /foo kann also nur mit einer Anfrage nach http://some.site/foo/bar/ übereinstimmen , nicht aber mit http://some.site/bar/foo/, auch wenn /foo dort irgendwo enthalten ist. Allerdings werden RegEx-Speicherorte etwas anders behandelt, wie wir später in diesem Artikel sehen werden, also bleiben Sie dran.

Präfixe für NGINX-Konfigurationsdateien

Wenn NGINX eine Anfrage bearbeitet, versucht es herauszufinden, welcher NGINX-Config-Speicherortblock zutrifft - es kann nur ein Speicherort zutreffen. Zu diesem Zweck wird die NGINX-Konfigurationsdatei von oben nach unten durchsucht - die Erstellung der Datei ist ein anderes Thema. Stellen Sie sich das Ganze einfach als eine NGINX-Konfigurationsdatei vor, die nach präfixartigen Speicherorten sucht. Immer wenn sie einen Ort findet, der mit der aktuellen Anfrage übereinstimmt, prüft sie, ob dieser Ort länger ist als der letzte, den sie gesehen hat. Ist dies der Fall, merkt sich NGINX die Adresse. Wenn der Speicherort genau passt und ein =-Typ ist, wird die Suche beendet und der Speicherortblock sofort verwendet, ohne dass RegEx-Speicherorte berücksichtigt werden. Beachten Sie, dass Orte vom Typ = überhaupt keine verschachtelten Orte enthalten können und NGINX dies als Fehler behandelt, wenn Sie es versuchen.

Wenn es innerhalb des neu gespeicherten Blocks verschachtelte Orte vom Typ Präfix gibt, werden diese zu diesem Zeitpunkt berücksichtigt, als ob sie auf der obersten Ebene definiert wären.

RegEx NGINX-Konfigurationsorte

Wenn NGINX das Ende der NGINX-Konfigurationsdatei erreicht, ohne einen =-Ort gefunden zu haben, wird der längste präfixartige Ort, der dieser Anfrage entspricht, aufgezeichnet. Anschließend werden alle RegEx-Speicherorte getestet, beginnend mit den Speicherorten, die innerhalb des übereinstimmenden Präfix-Typs definiert sind. Bei der ersten Übereinstimmung wird die Suche abgebrochen und einfach der entsprechende NGINX-Konfigurationsdatenblock verwendet. Wenn das Ende des Präfix-Typ-Speicherplatzes keine Übereinstimmung ergibt, wird weiter am Anfang der NGINX-Konfigurationsdatei gesucht.

Bitte beachten Sie: Es gibt eine Ausnahme: NGINX sucht innerhalb des übereinstimmenden Speicherplatzblocks nach tiefer verschachtelten RegEx-Speicherplatzblöcken, die übereinstimmen.

Es ist nicht möglich, einen präfixartigen Speicherplatzblock innerhalb eines regexartigen Speicherplatzblocks zu verschachteln, und NGINX wird dies als Fehler melden, wenn Sie es versuchen.

Schließlich gibt es noch eine letzte Ausnahme für das, was passiert, nachdem die Suche nach Präfixen in der NGINX-Konfiguration abgeschlossen ist. Wenn der beste Präfix-Typ-Speicherplatz-Block den strong-prefix-Modifikator(^~) enthält, werden überhaupt keine RegEx-Speicherplätze überprüft, mit Ausnahme von verschachtelten RegEx-Speicherplätzen.

Teilen Sie Ihre Erkenntnisse über NGINX-Konfigurationsorte mit Upsun

Ich hoffe, das war hilfreich für die anderen NGINX-Forscher da draußen. Ich bin vor einiger Zeit in das Kaninchenloch der NGINX-Konfigurationsverwicklungen gesprungen und fand es überraschend schwierig, eine vollständige Antwort zu finden. Haben Sie schon einmal Ihre eigene NGINX-Untersuchung durchgeführt? Was haben Sie herausgefunden?

Tauschen Sie sich aus, chatten Sie, diskutieren Sie - lassen Sie uns Ihre Gedanken und Erkenntnisse auf Discord wissen.