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
Zu deutsch. “Location-Blöcke können verschachtelt werden, mit unten genannten Außnahmen”, und haben sich gedacht: "Wow, das ist so unspezifisch. Was bedeutet das Verschachteln von location-Blöcken eigentlich? Warum sollte ich das tun?"
Nun, ich habe die nginx-Konfiguration eingehend untersucht und kann Ihnen Einblicke in meine Erkenntnisse bieten. Sie können jederzeit einen Blick in die NGINX-Dokumentation werfen, wenn Sie eine Auffrischung benötigen, wie NGINX Location-Blöcke in der Konfiguration funktionieren.
Es können vier Arten wie NGINX-Konfigurations-Locations definiert werden, die ich wie folgt bezeichnen möchte:
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. Die Location /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-Location etwas anders behandelt, wie wir später in diesem Artikel sehen werden, also bleiben Sie dran.
Wenn NGINX eine Anfrage bearbeitet, versucht es herauszufinden, welcher NGINX-Konfigurations-Location Block zutrifft - es kann nur eine Location zutreffen. Zu diesem Zweck wird die NGINX-Konfigurationsdatei zeilenweise durchsucht - die Erstellung der Konfigurationsdatei ist ein anderes Thema. Das ganze steht einer NGINX-Konfigurationsdatei vor, die nach präfixartigen Locations sucht. Immer wenn sie eine Location findet, die mit der aktuellen Anfrage übereinstimmt, prüft sie, ob diese Location länger ist als der letzte, den sie gesehen hat. Ist dies der Fall, merkt sich NGINX die Adresse. Wenn die Location genau passt und ein =
-Typ ist, wird die Suche beendet und der Location Block sofort verwendet, ohne dass RegEx-Locations berücksichtigt werden. Hier zu beachten ist, dass Locations vom Typ- =
überhaupt keine verschachtelten Locations enthalten können und NGINX dies als Fehler behandelt, wenn Sie es versuchen.
Wenn es innerhalb des neu gespeicherten Blocks verschachtelte Locations vom Typ Präfix gibt, werden diese zu diesem Zeitpunkt berücksichtigt, als ob sie auf der obersten Ebene definiert wären.
Wenn NGINX das Ende der NGINX-Konfigurationsdatei erreicht, ohne eine =
-Location gefunden zu haben, wird die längste präfix-Location, die dieser Anfrage entspricht, übernommen. Anschließend werden alle RegEx-Locations getestet, beginnend mit den Locations, die innerhalb des übereinstimmenden Präfix-Typs definiert sind. Bei der ersten Übereinstimmung wird die Suche abgebrochen und einfach der entsprechende NGINX-Konfigurations-Location Block verwendet. Wenn das Ende der Präfix-Typ-Locations keine Übereinstimmung ergibt, wird weiter am Anfang der NGINX-Konfigurationsdatei gesucht.
Es ist nicht möglich, einen präfix-Location Block innerhalb eines RegEx.Location Block zu verschachteln, NGINX wird dies als Fehler melden, wenn dies versucht wird.
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-Location-Block den strong-präfix-Modifikator(^~
) enthält, werden überhaupt keine RegEx Locations überprüft, mit Ausnahme von verschachtelten RegEx-Locations.
Ich hoffe, das war hilfreich für die NGINX-Forscher da draußen. Ich bin vor einiger Zeit in das Kaninchenbau der NGINX-Konfigurationsverwicklungen gesprungen und fand es überraschend schwierig, eine vollständige Antwort zu finden. Haben Sie schon einmal Ihre eigene NGINX-Forschung durchgeführt? Was haben Sie herausgefunden?
Teile es mit uns, chatte , diskutiere - lasse uns deine Gedanken und Erkenntnisse auf Discord erfahren.