Detaillierte Erläuterung der Fallstricke von add_header im Nginx-Konfigurationstutorial

Vorwort

add_header ist eine Direktive, die im Header-Modul definiert ist. Wie der Name schon sagt, wird sie zum Hinzufügen von HTTP-Antwortheadern verwendet. Beachten Sie jedoch, dass es lediglich „hinzugefügt“ und nicht neu geschrieben wird. Wenn also bereits ein Header vorhanden ist, verursacht die Verwendung von add_header Probleme. Darüber hinaus unterstützt add_header in früheren Versionen von nginx nicht die Verwendung auf Fehlerseiten.

Dies ist ein Befehl mit vielen Fallstricken. Seine Verarbeitungsphase ist später als die Standortverarbeitung. Obwohl es an einem Standort geschrieben werden kann, geht der add_header, der am vorherigen Standort nicht verarbeitet wurde, verloren, wenn ein anderer Standort neu geschrieben wird. Zum Beispiel:

Standort = /a {
 add_header eine 1;
 //b umschreiben;
}
Standort = /b {
 add_header b 2;
 Rückgabe 204;
} 

Es gibt keinen Kopf mit einer 1, oder? Das ist eine Grube!

Eine weitere Falle ist das eingangs erwähnte Duplizierungsproblem. Ich möchte beispielsweise für einen Inhalt den Content-Type festlegen, aber da global ein default_type festgelegt ist, wird dieser wiederholt.

Standardtyp „Text/Plain“;

Standort = /a {
 add_header Inhaltstyp application/json;
 gibt 200 ‚‚OK‘‘ zurück;
} 

Es gibt natürlich viele Lösungen, wie z. B. den Standardtyp für diesen Speicherort leer zu lassen oder einfach „add_header“ nicht zu verwenden und den Standardtyp für diesen Speicherort direkt zu ändern.

Die letzte große Falle besteht darin, dass es auf Fehlerseiten nicht funktioniert, was im Dokument auch klar definiert ist. Beispielsweise das folgende Beispiel:

Standort = /a {
 add_header Inhaltstyp application/json;
 return 404 ‚‚Nicht gefunden‘‘;
}

Ich möchte mit einem JSON antworten, aber da der Statuscode 404 ist, hat add_header hier keine Wirkung.

Obwohl dieses Beispiel das Problem mit dem Standardtyp lösen kann, was ist, wenn es sich um andere Header handelt? Was soll ich beispielsweise mit Access-Control-Allow-Origin tun? Dann gibt es keine Lösung außer der Verwendung von Lua oder anderen Drittanbietermodulen. Natürlich ist nginx sich dieses Problems bewusst, daher heißt es im Dokument auch, dass ab Version 1.7.5 ein Parameter namens „always“ unterstützt wird. Obwohl nginx selbst dieses Problem löst, wird es bei tengine basierend auf 1.6.2 Probleme geben.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Wenn Sie Fragen haben, können Sie eine Nachricht hinterlassen. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.