Heim  >  Artikel  >  Web-Frontend  >  Beispielfreigabe für den Nginx-Standortabgleich

Beispielfreigabe für den Nginx-Standortabgleich

小云云
小云云Original
2018-02-12 15:45:251740Durchsuche

In diesem Artikel werden hauptsächlich Beispiele für den Nginx-Standortabgleich vorgestellt. Da das Team das Front-End und das Back-End trennt, übernimmt das Front-End die Nginx- und Knotenebene mit Nginx. Ich wusste vorher nicht viel über Standort-Matching-Regeln. Um zu verstehen, wie Standorte zugeordnet werden, hoffe ich, dass es allen helfen kann.

Grammatikregeln

location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }

Die Grammatikregeln sind sehr einfach, ein Schlüsselwort location, gefolgt von optionalen Modifikatoren, gefolgt von den Zeichen, die abgeglichen werden sollen, und die geschweiften Klammern sind es auszuführenden Vorgang.

Modifikator

  • = bedeutet eine genaue Übereinstimmung. Ein Treffer erfolgt nur, wenn der angeforderte URL-Pfad genau mit der folgenden Zeichenfolge übereinstimmt.

  • ~ gibt an, dass die Regel mithilfe regulärer Ausdrücke definiert ist und die Groß-/Kleinschreibung beachtet wird.

  • ~* gibt an, dass die Regel mithilfe regulärer Ausdrücke definiert ist und die Groß-/Kleinschreibung nicht beachtet wird.

  • ^~ bedeutet, dass diese Regel verwendet wird und keine nachfolgende Suche durchgeführt wird, wenn das Zeichen nach dem Symbol am besten übereinstimmt.

Der Matching-Prozess

serialisiert die angeforderte URL. Dekodieren Sie beispielsweise Zeichen wie %xx, entfernen Sie mehrere verbundene / in der URL und analysieren Sie ., .. usw. in der URL. Dieser Schritt ist die Vorarbeit für das Matching.

Standort hat zwei Darstellungsformen: Eine besteht darin, Präfixzeichen zu verwenden, und die andere darin, reguläre Ausdrücke zu verwenden. Wenn es regelmäßig ist, steht davor der Modifikator ~ oder ~*.

Der spezifische Matching-Prozess ist wie folgt:

Überprüfen Sie zunächst den mithilfe des Präfixzeichens definierten Ort, wählen Sie das am längsten passende Element aus und zeichnen Sie es auf.

Wenn ein genau passender Standort gefunden wird, also ein Standort, der den Modifikator = verwendet, beenden Sie die Suche und verwenden Sie seine Konfiguration.

Suchen Sie dann die mit regulären Ausdrücken definierten Orte der Reihe nach. Wenn sie übereinstimmen, beenden Sie die Suche und verwenden Sie die definierte Konfiguration.

Wenn es keinen passenden regulären Ort gibt, wird der längste zuvor aufgezeichnete Ort des übereinstimmenden Präfixzeichens verwendet.

Basierend auf dem obigen Abgleichsprozess können wir die folgenden zwei Erkenntnisse gewinnen:

  1. Die Reihenfolge, in der mithilfe regulärer Ausdrücke definierte Standorte in der Konfigurationsdatei erscheinen ist wichtig. Denn nachdem das erste passende reguläre Muster gefunden wurde, stoppt die Suche und nachfolgende definierte reguläre Muster haben keine Chance mehr, erneut zuzuordnen.

  2. Die Verwendung einer genauen Übereinstimmung kann die Suche beschleunigen. Wenn Sie beispielsweise häufig / anfordern, können Sie = verwenden, um den Standort zu definieren.

Beispiel

Als nächstes erklären wir anhand eines Beispiels den Matching-Prozess im Detail.

Angenommen, wir haben die folgende Konfigurationsdatei:

location = / {
    [ configuration A ]
}

location / {
    [ configuration B ]
}

location /user/ {
    [ configuration C ]
}

location ^~ /images/ {
    [ configuration D ]
}

location ~* \.(gif|jpg|jpeg)$ {
    [ configuration E ]
}

Fordern Sie / an, genau mit A übereinzustimmen und nicht mehr weiter zu suchen.

Anfrage/index.html entspricht B. Suchen Sie zunächst nach passenden Präfixzeichen, suchen Sie die längste passende Konfiguration B und suchen Sie dann der Reihe nach nach passenden regulären Regeln. Das Ergebnis wurde nicht gefunden, daher wird die längste Übereinstimmung aus dem vorherigen Tag verwendet, also Konfiguration B.

Anfrage/user/index.html entspricht C. Finden Sie zunächst das am längsten passende C. Da es später kein passendes reguläres Muster gibt, wird das am längsten passende C verwendet.
Anfrage/user/1.jpg entspricht E. Suchen Sie zunächst nach den Präfixzeichen, um das am längsten übereinstimmende Element C zu finden. Setzen Sie dann die reguläre Suche fort und finden Sie das übereinstimmende Element E. Verwenden Sie also E.

Anfrage/images/1.jpg entspricht D. Suchen Sie zunächst nach Präfixzeichen und finden Sie die längste Übereinstimmung D. Das Besondere ist jedoch, dass der Modifikator ^~ verwendet wird und die anschließende reguläre Matching-Suche nicht mehr durchgeführt wird, sodass D verwendet wird. Wenn hier keine vorherigen Modifikatoren vorhanden sind, ist die endgültige Übereinstimmung tatsächlich E. Sie können darüber nachdenken, warum.

Anfrage/documents/about.html entspricht B. Denn B bedeutet, dass jede URL, die mit / beginnt, übereinstimmt. In der obigen Konfiguration kann nur B diese erfüllen, sodass B übereinstimmt.

Verwendung des Standort-@Namens

@ wird verwendet, um einen benannten Standort zu definieren. Wird hauptsächlich zur internen Umleitung verwendet und kann nicht zur Bearbeitung normaler Anfragen verwendet werden. Seine Verwendung ist wie folgt:

location / {
    try_files $uri $uri/ @custom
}
location @custom {
    # ...do something
}

Wenn Sie im obigen Beispiel versuchen, auf die URL zuzugreifen und die entsprechende Datei nicht finden können, wird sie an unseren benutzerdefinierten benannten Speicherort (hier benutzerdefiniert) umgeleitet.

Es ist zu beachten, dass der benannte Standort keine anderen benannten Standorte verschachteln kann .

Ist das / am Ende der URL notwendig

Es gibt drei Punkte zum / am Ende der URL, die erklärt werden müssen. Der erste Punkt bezieht sich auf die Standortkonfiguration, die anderen beiden Punkte haben damit nichts zu tun. Es hat keine Auswirkung darauf, ob die Zeichen in

  1. location / enthalten oder nicht. Mit anderen Worten, /user/ und /user sind gleich.

  2. Wenn die URL-Struktur die Form https://domain.com/ hat, erfolgt keine Umleitung, unabhängig davon, ob am Ende ein / steht. Weil der Browser bei einer Anfrage standardmäßig / hinzufügt. Obwohl viele Browser / nicht in der Adressleiste anzeigen. Sie können dies überprüfen, indem Sie Baidu besuchen.

  3. Wenn die Struktur der URL https://domain.com/some-dir/ ist. Das Fehlen von / am Ende führt zu einer Weiterleitung. Denn gemäß der Konvention stellt das / am Ende der URL das Verzeichnis dar, und das Fehlen von / stellt die Datei dar. Daher geht der Server beim Zugriff auf /some-dir/ automatisch in das Verzeichnis, um die entsprechende Standarddatei zu finden. Wenn Sie auf /some-dir zugreifen, sucht der Server zunächst nach der Datei some-dir. Wenn er sie nicht finden kann, behandelt er some-dir als Verzeichnis und leitet zu /some-dir/ um, um die Standarddatei in diesem Verzeichnis zu finden. Sie können Ihre Website testen, um festzustellen, ob dies der Fall ist.

Zusammenfassung

Es gibt zwei Formen der Standortkonfiguration: Präfixzeichen und reguläre Ausdrücke. Suchen Sie bei der Suche nach einer Übereinstimmung zuerst nach dem Präfixzeichen, wählen Sie die längste Übereinstimmung aus und suchen Sie dann nach dem regulären Muster. Reguläre Zeichen haben eine höhere Priorität als Präfixzeichen.

Regelmäßige Suchvorgänge werden in der Reihenfolge in der Konfigurationsdatei durchgeführt. Daher ist die Reihenfolge der regulären Ausdrücke sehr wichtig. Es wird empfohlen, die detaillierteren Ausdrücke zuerst zu platzieren.

Die Verwendung von = mit präzisem Abgleich kann die Suchsequenz beschleunigen. Wenn häufig auf den Stammdomänennamen zugegriffen wird, wird die Verwendung von = empfohlen.

Verwandte Empfehlungen:

Javascript-Methode zum Aktualisieren der Seite und Einführung in die Verwendung von location.reload()

Beherrschen Sie $location in AngularJS vollständig

Hinweise zum Sprung der PHP-Programm-Header-Position


Das obige ist der detaillierte Inhalt vonBeispielfreigabe für den Nginx-Standortabgleich. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn