Beispielanalyse der Nginx add_header-Anweisung

Vorwort

Wie wir alle wissen, legt die Nginx-Konfigurationsdatei den Antwortheader mithilfe der Anweisung add_header fest.

Als ich Curl verwendet habe, um die Informationen einer Site zu überprüfen, habe ich festgestellt, dass der zurückgegebene Header anders ist als erwartet:

http/2 200
date: thu, 07 feb 2019 04:26:38 gmt
content-type: text/html; charset=utf-8
vary: accept-encoding, cookie
cache-control: max-age=3, must-revalidate
last-modified: thu, 07 feb 2019 03:54:54 gmt
x-cache: miss
server: cloudflare
...

Die Hauptsite hat HSTs und andere Header in nginx.conf konfiguriert:

add_header strict-transport-security "max-age=63072000; preload";
add_header x-frame-options sameorigin;
add_header x-content-type-options nosniff;
add_header x-xss-protection "1; mode=block";

Der Antwortheader jedoch schon nicht über diese Header verfügen. Zusätzlich zu den regulären Headern ist am Standort nur ein Header-X-Cache konfiguriert.

Der erste Eindruck ist, dass CDN diese Header filtert? Also habe ich nach der Dokumentation von Cloudflare gesucht, aber nicht gefunden, dass diese damit umgehen kann. Dann habe ich darüber nachgedacht: Was macht CDN, um diese zu filtern? Sind Sie nach dem Essen satt? Sie betreiben keine Zensur!

Das Problem verlagert sich auf die Nginx-Konfiguration. Öffnen Sie Google und suchen Sie nach „nginx location add_header“. Sie werden viele Fehler finden. Klicken Sie auf das add_header-Dokument auf der offiziellen Website und es gibt diese Beschreibung (weitere Informationen wurden weggelassen):

Es könnten mehrere add_header-Anweisungen vorhanden sein. Diese Anweisungen werden genau dann von der vorherigen Ebene geerbt, wenn keine add_header-Anweisungen definiert sind auf der aktuellen Ebene .

Die Aufmerksamkeit liegt auf „Diese Anweisungen werden genau dann von der vorherigen Ebene geerbt, wenn auf der aktuellen Ebene keine add_header-Anweisungen definiert sind.“ Das heißt: Die übergeordneten Einstellungen werden nur vererbt, wenn in der aktuellen Ebene keine add_header-Direktive vorhanden ist. Meine Frage ist also klar: Es gibt add_header in location und die Konfiguration in nginx.conf wird verworfen.

Dies ist ein absichtliches Verhalten von Nginx und kann nicht als Fehler oder Falle bezeichnet werden. Wenn Sie diesen Satz jedoch genau verstehen, werden Sie ein interessanteres Phänomen feststellen: Nur der neueste add_header funktioniert. add_header kann in http, Server und Standort konfiguriert werden, aber die nächstgelegene Konfiguration wird wirksam und alle oben genannten Konfigurationen sind ungültig.

Aber das Problem hört hier nicht auf. Wenn der Speicherort an einen anderen Speicherort umgeschrieben wird, erscheint im Endergebnis nur die zweite Kopfzeile. Zum Beispiel:

location /foo1 {
 add_header foo1 1;
 rewrite / /foo2;
}

location /foo2 {
 add_header foo2 1;
 return 200 "ok";
}

Unabhängig davon, ob /foo1 oder /foo2 angefordert wird, ist der letzte Header nur foo2:

Obwohl es Sinn macht, dass dies ein normales Verhalten ist, fühlt es sich immer etwas erzwungen und unangenehm an: Der Server verliert die http-Konfiguration und der Standort gehen verloren. Die Serverkonfiguration ist in Ordnung, aber die beiden Standorte sind auf dem gleichen Stand!

Sie können die übergeordnete Konfiguration nicht erben und möchten keine Anweisungen im aktuellen Block wiederholen. Die Lösung kann darin bestehen, die Include-Anweisung zu verwenden.

Das obige ist der detaillierte Inhalt vonBeispielanalyse der Nginx add_header-Anweisung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!