Werden HTTP-Header vom CDN oder von der Anwendung konfiguriert?

Werden HTTP-Header vom CDN oder von der Anwendung konfiguriert?

Dies ist eine eher theoretische Frage und ich vermute, dass sie möglicherweise zu allgemein oder unklar ist.

Foobar ist eine Anwendung, die Benutzer im gesamten Internet bedient. Sie verlässt sich auf ein CDN, um ihre Belastbarkeit, Geschwindigkeit usw. zu verbessern und den Benutzern überall zur Verfügung zu stehen.

  • Werden die (vom Client empfangenen) HTTP-Header vom CDN oder von der Foobar-Anwendung definiert (was bedeutet, dass das CDN sie weiterleitet)?

  • Wenn beides möglich ist, was sind die Vor- und Nachteile der jeweiligen Variante?

Antwort1

Darauf gibt es keine allgemeingültige Antwort. Was mit Headern gemacht wird, hängt sowohl von der Anfrage, dem spezifischen CDN, dem spezifischen Header als auch von Ihrer Site-Konfiguration ab (dazu gehören sowohl die Header, die Ihr Backend/Ursprungsserver in die Antwort einfügt, als auch davon, wie Sie Ihre Site im CDN konfigurieren).

Nehmen wir an, dass standardmäßig die Mehrheit derHeader werden entferntaus der Antwort eines Back-End/Origin-Servers und nur einer (minimalen)Teilmenge der Header wird gesetztin der vom CDN gesendeten Antwort.

Einige (CDN-spezifische) HeaderkönnteSeihinzugefügtvom CDN gemäß Ihren Richtlinien oder standardmäßig. Beispielsweise fügt Fastly einx-served-by:Header standardmäßig und CloudFront ermöglicht Ihnen das Festlegen und optional Server-Timing:Headerum das Debuggen von CDN-Vorgängen zu erleichtern.

Einige ÜberschriftenkönnteSeikonserviertvon Ihrem Back-End-Server. Beispielsweise sind Cache-control:und Expires:Header recht häufig. Siehe zum Beispiel:Cloud Front-Dokumente

ManchekönnteSeiangepasstvom CDN auf bestimmte Weise. Sehen Sie sich beispielsweise an, wie Fastly mit einemDate:Headerim Ursprung gesetzt.


Gründe für das Setzen von Headern im CDN

Anstatt jeder Anwendung zu erlauben, ihr eigenes Ding zu machen oder gar nichts zu machen, legen Sie auf CDN-Ebene eine einzige Richtlinie für alle Ihre Sites und Anwendungen fest.

Gute Beispiele sindCORSUndHSTSRichtlinien.

Sie können sich dafür entscheiden, nur dann einen bestimmten Header beim CDN festzulegen/hinzuzufügen, wenn dies beim Ursprung nicht der Fall ist, aber den Wert vom Ursprung zu verwenden, wenn dieser dort festgelegt ist.

usw. usw.


Gründe für die Beibehaltung der am Ursprung festgelegten Header

Der Anwendungsentwickler weiß am besten, was die Anwendung benötigt.

Das Überschreiben der Standard-Caching-Richtlinie durch Cache-Control: private, no-storeist ein Paradebeispiel, das mir in den Sinn kommt.

usw. usw.

verwandte Informationen