View a markdown version of this page

Grundlegendes zu Antwortheader-Richtlinien - Amazon CloudFront
Richtliniendetails (Metadaten)CORS-HeaderSicherheits-HeaderBenutzerdefinierte HeaderEntfernen von HeadernServer-Timing Kopfzeile

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Grundlegendes zu Antwortheader-Richtlinien

Sie können eine Richtlinie für Antwort-Header verwenden, um die HTTP-Header festzulegen, die Amazon CloudFront entfernt oder in Antworten, die es an Zuschauer sendet, hinzufügt. Weitere Informationen zu Antwort-Header-Richtlinien und zu Gründen für ihre Verwendung finden Sie unter Hinzufügen oder Entfernen von HTTP-Headern in CloudFront Antworten mit einer Richtlinie.

In den folgenden Themen werden die Einstellungen in einer Antwort-Header-Richtlinie erläutert. Die Einstellungen sind in Kategorien unterteilt, die in den folgenden Themen behandelt werden.

Richtliniendetails (Metadaten)

Die Einstellungen für Richtliniendetails enthalten Metadaten zu einer Antwort-Header-Richtlinie.

  • Name – Ein Name zur Identifizierung der Antwort-Header-Richtlinie. Verwenden Sie den Namen in der Konsole, um die Richtlinie einem Cache-Verhalten anzufügen.

  • Beschreibung (optional) – Ein Kommentar zur Beschreibung der Antwort-Header-Richtlinie. Dies ist optional, kann Ihnen jedoch helfen, den Zweck der Richtlinie zu identifizieren.

CORS-Header

Mit den Cross-Origin Resource Sharing (CORS)-Einstellungen können Sie CORS-Header in einer Antwort-Header-Richtlinie hinzufügen und konfigurieren.

Bei dieser Liste liegt der Fokus darauf, wie Einstellungen und gültige Werte in einer Antwort-Header-Richtlinie angegeben werden. Weitere Informationen zu den jeweiligen Headern und deren Verwendung für reale CORS-Anforderungen und -Antworten finden Sie unter Cross-Origin Resource Sharing in den MDN-Webdokumenten und in der CORS-Protokollspezifikation.

Access-Control-Allow-Credentials

Dies ist eine boolesche Einstellung (trueoderfalse), die bestimmt, ob der Access-Control-Allow-Credentials Header in Antworten auf CORS-Anfragen CloudFront hinzugefügt wird. Wenn diese Einstellung auf gesetzt isttrue, wird der Access-Control-Allow-Credentials: true Header in Antworten auf CORS-Anfragen CloudFront hinzugefügt. Andernfalls wird dieser Header CloudFront nicht zu den Antworten hinzugefügt.

Access-Control-Allow-Headers

Gibt die Header-Namen an, die als Werte für den Access-Control-Allow-Headers Header in Antworten auf CORS-Preflight-Anfragen CloudFront verwendet werden. Zu den gültigen Werten für diese Einstellung gehören HTTP-Header-Namen oder das Platzhalterzeichen (*), das anzeigt, dass alle Header zulässig sind.

Anmerkung

Der Authorization-Header darf keinen Platzhalter verwenden und muss explizit aufgeführt werden.

Beispiele für die gültige Verwendung des Platzhalterzeichens
Beispiel Übereinstimmung mit Keine Übereinstimmung mit

x-amz-*

x-amz-test

x-amz-

x-amz

x-*-amz

x-test-amz

x--amz
* Alle Header außer Authorization Authorization
Access-Control-Allow-Methods

Gibt die HTTP-Methoden an, die als Werte für den Access-Control-Allow-Methods Header in Antworten auf CORS-Preflight-Anfragen CloudFront verwendet werden. Gültige Werte sind GET, DELETE, HEAD, OPTIONS, PATCH, POST, PUT und ALL. ALL ist ein spezieller Wert, der alle aufgelisteten HTTP-Methoden enthält.

Access-Control-Allow-Origin

Gibt die Werte an, die im Access-Control-Allow-Origin Antwortheader verwendet werden CloudFront können. Zu den gültigen Werten für diese Einstellung gehören ein spezifischer Ursprung (z. B. http://www.example.com) oder das Platzhalterzeichen (*), das angibt, dass alle Ursprünge zulässig sind.

Hinweise

  • Das Platzhalterzeichen (*) ist als äußerster linker Teil der Subdomain (*.example.org) zulässig.

  • Das Platzhalterzeichen (*) ist an folgenden Stellen nicht zulässig:

    • Top-level Domänen (example.*)

    • rechts neben Subdomains (test.*.example.org) oder innerhalb beliebiger Subdomains (*test.example.org)

    • Innerhalb von Begriffen (exa*mple.org)

Beispiele für die Verwendung des Platzhalterzeichens finden Sie in der folgenden Tabelle.

Beispiel Übereinstimmung mit Keine Übereinstimmung mit

http://*.example.org

http://www.example.org

http://test.example.org

https://test.example.org

https://test.example.org:123

http://test.example.org:123

*.example.org

test.example.org

test.test.example.org

.example.org

http://test.example.org

https://test.example.org

http://test.example.org:123

https://test.example.org:123

example.org

http://example.org

https://example.org

http://example.org

https://example.org

http://example.org:123

http://example.org:*

http://example.org:123

http://example.org

http://example.org:1*3

http://example.org:123

http://example.org:1893

http://example.org:13

*.example.org:1*

test.example.org:123
Access-Control-Expose-Headers

Gibt die Header-Namen an, die als Werte für den Access-Control-Expose-Headers Header in Antworten auf CORS-Anfragen CloudFront verwendet werden. Zu den gültigen Werten für diese Einstellung gehören HTTP-Header-Namen oder das Platzhalterzeichen (*).

Access-Control-Max-Age

Eine Anzahl von Sekunden, die als Wert für den Access-Control-Max-Age Header bei Antworten auf CORS-Preflight-Anfragen CloudFront verwendet wird.

Origin override (Ursprungsüberschreibung)

Eine boolesche Einstellung, die bestimmt, wie CloudFront sich verhält, wenn die Antwort vom Ursprung einen der CORS-Header enthält, die auch in der Richtlinie enthalten sind.

  • Wenn dieser Wert auf gesetzt ist true und die Quellantwort einen CORS-Header enthält, der ebenfalls in der Richtlinie enthalten ist, wird der Antwort der CORS-Header in der Richtlinie CloudFront hinzugefügt. CloudFront sendet dann diese Antwort an den Betrachter. CloudFront ignoriert den Header, den es vom Ursprung erhalten hat.

  • Wenn dieser Wert auf gesetzt ist false und die Quellantwort einen CORS-Header enthält (unabhängig davon, ob der CORS-Header in der Richtlinie enthalten ist), CloudFront schließt er den CORS-Header ein, den sie vom Ursprung in die Antwort erhalten hat. CloudFront fügt der Antwort, die an den Betrachter gesendet wird, keine CORS-Header in der Richtlinie hinzu.

Sicherheits-Header

Mit den Einstellungen für Sicherheits-Header können Sie mehrere sicherheitsbezogene HTTP-Antwort-Header in einer Antwort-Header-Richtlinie hinzufügen und konfigurieren.

Diese Liste beschreibt, wie Sie Einstellungen und gültige Werte in einer Antwort-Header-Richtlinie angeben können. Weitere Informationen zu diesen Headern und ihrer Verwendung in realen HTTP-Antworten finden Sie unter den Links zu den MDN-Webdokumenten.

Content-Security-Policy

Gibt die Richtlinien für Inhaltssicherheitsrichtlinien an, die als Werte für den Content-Security-Policy Antwortheader CloudFront verwendet werden.

Weitere Informationen zu diesem Header und den gültigen Richtlinien finden Sie unter Content-Security-Policy in den MDN-Webdokumenten.

Anmerkung

Der Content-Security-Policy-Header-Wert ist auf 1783 Zeichen begrenzt.

Referrer-Policy

Gibt die Referrer-Richtlinienrichtlinie an, die als Wert für den Referrer-Policy Antwortheader CloudFront verwendet wird. Gültige Werte für diese Einstellung sind no-referrer, no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin und unsafe-url.

Weitere Informationen zu diesem Header und diesen Richtlinien finden Sie unter Referrer-Policy in den MDN-Webdokumenten.

Strict-Transport-Security

Gibt die Anweisungen und Einstellungen an, die als Wert für den Strict-Transport-Security Antwortheader CloudFront verwendet werden. Für diese Einstellung geben Sie separat Folgendes an:

  • Eine Anzahl von Sekunden, die als Wert für die max-age Direktive dieses Headers CloudFront verwendet wird

  • Eine boolesche Einstellung (trueoderfalse) fürpreload, die bestimmt, ob CloudFront die preload Direktive in den Wert dieses Headers aufgenommen wird

  • Eine boolesche Einstellung (trueoderfalse) fürincludeSubDomains, die bestimmt, ob die includeSubDomains Direktive in CloudFront den Wert dieses Headers aufgenommen wird

Weitere Informationen zu diesem Header und diesen Richtlinien finden Sie unter Strict-Transport-Security in den MDN-Webdokumenten.

X-Content-Type-Options

Dies ist eine boolesche Einstellung (trueoderfalse), die bestimmt, ob der Header zu Antworten CloudFront hinzugefügt wirdX-Content-Type-Options. Wenn diese Einstellung aktiviert isttrue, wird der X-Content-Type-Options: nosniff Header zu den Antworten CloudFront hinzugefügt. Andernfalls CloudFront wird dieser Header nicht hinzugefügt.

Weitere Informationen zu diesem Header finden Sie unter X-Content-Type-Options in den MDN-Webdokumenten.

X-Frame-Options

Gibt die Direktive an, die als Wert für den X-Frame-Options Antwortheader CloudFront verwendet wird. Gültige Werte für diese Einstellung sind DENY oder SAMEORIGIN.

Weitere Informationen zu diesem Header und diesen Richtlinien finden Sie unter X-Frame-Options in den MDN-Webdokumenten.

X-XSS-Protection

Gibt die Direktiven und Einstellungen an, die als Wert für den X-XSS-Protection Antwortheader CloudFront verwendet werden. Für diese Einstellung geben Sie separat Folgendes an:

  • Die X-XSS-Protection-Einstellung 0 (deaktiviert XSS-Filterung) oder 1 (aktiviert XSS-Filterung)

  • Eine boolesche Einstellung (trueoderfalse) fürblock, die bestimmt, ob die mode=block Direktive CloudFront in den Wert für diesen Header aufgenommen wird

  • Ein Berichts-URI, der bestimmt, ob CloudFront die report=reporting URI Direktive in den Wert für diesen Header aufgenommen wird

Sie können true für block oder einen Berichts-URI angeben. Sie können jedoch nicht beides zusammen angeben. Weitere Informationen zu diesem Header und diesen Richtlinien finden Sie unter X-XSS-Protection in den MDN-Webdokumenten.

Origin override (Ursprungsüberschreibung)

Jede dieser Sicherheits-Header-Einstellungen enthält eine boolesche Einstellung (trueoderfalse), die bestimmt, wie CloudFront sich verhält, wenn die Antwort vom Ursprung diesen Header enthält.

Wenn diese Einstellung auf gesetzt ist true und die Quellantwort den Header enthält, wird der Header in der Richtlinie zu der Antwort CloudFront hinzugefügt, die an den Viewer gesendet wird. Der vom Ursprung empfangene Header wird dabei ignoriert.

Wenn diese Einstellung auf gesetzt ist false und die ursprüngliche Antwort den Header enthält, CloudFront schließt sie den Header, den sie vom Ursprung erhalten hat, in die Antwort ein, die sie an den Viewer sendet.

Wenn die ursprüngliche Antwort den Header nicht enthält, wird der Antwort, die an den Betrachter gesendet wird, den Header in der Richtlinie CloudFront hinzugefügt. CloudFront tut dies, wenn diese Einstellung auf true oder gesetzt istfalse.

Benutzerdefinierte Header

Sie können benutzerdefinierte Header-Einstellungen verwenden, um benutzerdefinierte HTTP-Header in einer Response-Header-Richtlinie hinzuzufügen und zu konfigurieren. CloudFront fügt diese Header zu jeder Antwort hinzu, die an die Zuschauer zurückgegeben wird. Bei benutzerdefinierten Headern geben Sie auch den Wert für den jeweiligen Header an, auch wenn die Angabe eines Werts optional ist. Dies liegt daran, dass ein Antwortheader ohne Wert hinzugefügt werden CloudFront kann.

Jeder benutzerdefinierte Header verfügt zudem über eine eigene Einstellung für Origin override (Ursprungsüberschreibung):

  • Wenn diese Einstellung auf gesetzt ist true und die Quellantwort den benutzerdefinierten Header enthält, der in der Richtlinie enthalten ist, wird der benutzerdefinierte Header in der Richtlinie zu der Antwort CloudFront hinzugefügt, die an den Viewer gesendet wird. Der vom Ursprung empfangene Header wird dabei ignoriert.

  • Wenn diese Einstellung aktiviert ist false und die Quellantwort den benutzerdefinierten Header enthält, der in der Richtlinie enthalten ist, CloudFront schließt sie den benutzerdefinierten Header, den sie vom Ursprung erhalten hat, in die Antwort ein, die an den Betrachter gesendet wird.

  • Wenn die ursprüngliche Antwort nicht den benutzerdefinierten Header enthält, der in der Richtlinie enthalten ist, CloudFront fügt der an den Betrachter gesendeten Antwort den benutzerdefinierten Header in der Richtlinie hinzu. CloudFront tut dies, wenn diese Einstellung auf true oder gesetzt istfalse.

Entfernen von Headern

Sie können Kopfzeilen angeben, die Sie aus den Antworten entfernen CloudFront möchten, die vom Absender empfangen werden, sodass die Kopfzeilen nicht in den Antworten enthalten sind, die an Zuschauer CloudFront gesendet werden. CloudFront entfernt die Header aus jeder Antwort, die an Zuschauer gesendet wird, unabhängig davon, ob die Objekte aus dem CloudFront Cache oder vom Ursprung aus bereitgestellt werden. Beispielsweise können Sie Header entfernen, die für Browser nutzlos sind, wie z. B. X-Powered-By oderVary, sodass diese Header aus den Antworten CloudFront entfernt werden, die an Zuschauer gesendet werden.

Wenn Sie mithilfe einer Richtlinie für Antwortheader zu entfernende Header angeben, werden die Header zuerst CloudFront entfernt und dann alle Header hinzugefügt, die in anderen Abschnitten der Richtlinie für Antwortheader angegeben sind (CORS-Header, Sicherheitsheader, benutzerdefinierte Header usw.). Wenn Sie einen Header angeben, der entfernt werden soll, denselben Header aber auch in einem anderen Abschnitt der Richtlinie hinzufügen, wird der Header in die Antworten aufgenommen, die an CloudFront die Zuschauer gesendet werden.

Anmerkung

Du kannst eine Richtlinie für Antwort-Header verwenden, um die Server Date Und-Header zu entfernen, die vom Absender CloudFront empfangen wurden, sodass diese Header (so, wie sie vom Absender empfangen wurden) nicht in den Antworten enthalten sind, die an Zuschauer CloudFront gesendet werden. In diesem Fall wird den Antworten, die an Zuschauer gesendet werden, jedoch eine eigene Version dieser Header CloudFront hinzugefügt. Für den Server Header, der CloudFront hinzugefügt wird, lautet CloudFront der Wert des Headers.

Header, die Sie nicht entfernen können

Sie können die folgenden Header nicht mithilfe einer Antwort-Header-Richtlinie entfernen. Wenn Sie diese Header im Abschnitt Remove headers (Header entfernen) einer Antwort-Header-Richtlinie (ResponseHeadersPolicyRemoveHeadersConfig in der API) angeben, erhalten Sie eine Fehlermeldung.

  • Connection

  • Content-Encoding

  • Content-Length

  • Expect

  • Host

  • Keep-Alive

  • Proxy-Authenticate

  • Proxy-Authorization

  • Proxy-Connection

  • Trailer

  • Transfer-Encoding

  • Upgrade

  • Via

  • Warning

  • X-Accel-Buffering

  • X-Accel-Charset

  • X-Accel-Limit-Rate

  • X-Accel-Redirect

  • X-Amz-Cf-.*

  • X-Amzn-Auth

  • X-Amzn-Cf-Billing

  • X-Amzn-Cf-Id

  • X-Amzn-Cf-Xff

  • X-Amzn-ErrorType

  • X-Amzn-Fle-Profile

  • X-Amzn-Header-Count

  • X-Amzn-Header-Order

  • X-Amzn-Lambda-Integration-Tag

  • X-Amzn-RequestId

  • X-Edge-.*

  • X-Forwarded-Proto

  • X-Real-Ip

Server-Timing Kopfzeile

Verwenden Sie die Server-Timing Header-Einstellung, um den Server-Timing Header in HTTP-Antworten zu aktivieren, die von gesendet wurden CloudFront. Sie können diesen Header verwenden, um Kennzahlen anzuzeigen, die Ihnen helfen können, Erkenntnisse über das Verhalten und die Leistung von CloudFront und Ihren Ursprung zu gewinnen. Sie können beispielsweise anzeigen, welche Cache-Ebene einen Cache-Treffer geliefert hat. Sie können auch die Latenz des ersten Byte vom Ursprung anzeigen, wenn ein Cache-Fehler vorliegt. Die Metriken in der Server-Timing Kopfzeile können Ihnen helfen, Probleme zu beheben oder die Effizienz Ihrer Konfiguration CloudFront oder Ihrer Originalkonfiguration zu testen.

Weitere Informationen zur Verwendung des Server-Timing Headers mit CloudFront finden Sie in den folgenden Themen.

Um den Header Server-Timing zu aktivieren, müssen Sie eine Antwort-Header-Richtlinie erstellen (oder bearbeiten).

Abtastrate und Pragma-Anforderungs-Header

Wenn Sie den Header Server-Timing in einer Antwort-Header-Richtlinie aktivieren, geben Sie auch die Abtastrate an. Die Stichprobenrate ist eine Zahl 0—100 (einschließlich), die den Prozentsatz der Beantwortungen angibt, CloudFront zu denen Sie die Server-Timing Kopfzeile hinzufügen möchten. Wenn Sie die Samplerate auf 100 festlegen, wird der HTTP-Antwort für jede Anforderung, die dem Cacheverhalten entspricht, an das die Richtlinie für Server-Timing Antwortheader angehängt ist, der Header CloudFront hinzugefügt. Wenn Sie den Wert auf 50 setzen, wird der Header zu 50% der Antworten für Anfragen CloudFront hinzugefügt, die dem Cacheverhalten entsprechen. Sie können als Abtastrate eine beliebige Zahl von 0 bis 100 mit bis zu vier Dezimalstellen festlegen.

Wenn die Sampling-Rate auf einen Wert unter 100 eingestellt ist, können Sie nicht kontrollieren, zu welchen Antworten der Server-Timing Header CloudFront hinzugefügt wird, sondern nur den Prozentsatz. Sie können jedoch den Header Pragma mit dem Wert server-timing in einer HTTP-Anforderung hinzufügen, um den Header Server-Timing in der Antwort auf diese Anforderung zu empfangen. Dies funktioniert unabhängig davon, auf welchen Wert die Abtastrate festgelegt ist. Selbst wenn die Sampling-Rate auf Null (0) gesetzt ist, wird der Server-Timing Header zur Antwort CloudFront hinzugefügt, wenn die Anfrage den Pragma: server-timing Header enthält.

Server-Timing Header vom Ursprung

Wenn ein Cache-Fehler auftritt und die Anfrage an den Ursprung CloudFront weitergeleitet wird, könnte der Ursprung in seiner Antwort auf CloudFront einen Server-Timing Header enthalten. In diesem Fall CloudFront fügt es seine Metriken dem Server-Timing Header hinzu, den es vom Ursprung erhalten hat. Die Antwort, die CloudFront an den Viewer gesendet wird, enthält einen einzelnen Server-Timing Header, der den Wert, der vom Ursprung stammt, und die CloudFront hinzugefügten Metriken enthält. Der Header-Wert vom Ursprung kann am Ende oder zwischen zwei Gruppen von Metriken stehen, die CloudFront den Header ergänzen.

Bei einem Cache-Treffer enthält die Antwort, die an den Viewer CloudFront gesendet wird, einen einzelnen Server-Timing Header, der nur die CloudFront Metriken im Header-Wert enthält (der Wert vom Ursprung ist nicht enthalten).

Server-Timing Header-Metriken

Wenn der Server-Timing Header zu einer HTTP-Antwort CloudFront hinzugefügt wird, enthält der Wert des Headers eine oder mehrere Metriken, die Ihnen helfen können, Erkenntnisse über das Verhalten und die Leistung von CloudFront und Ihren Ursprung zu gewinnen. Die folgende Liste enthält alle Metriken und ihre möglichen Werte. Ein Server-Timing Header enthält nur einige dieser Metriken, abhängig von der Art der Anfrage und der Antwort CloudFront.

Einige dieser Metriken sind nur mit einem Namen (ohne Wert) im Header Server-Timing enthalten. Andere bestehen aus einem Namen und einem Wert. Wenn eine Metrik einen Wert aufweist, werden Name und Wert durch ein Semikolon (;) getrennt. Wenn der Header mehr als eine Metrik enthält, werden die Metriken durch ein Komma (,) getrennt.

cdn-cache-hit

CloudFront hat eine Antwort aus dem Cache bereitgestellt, ohne eine Anfrage an den Ursprung zu stellen.

cdn-cache-refresh

CloudFront hat eine Antwort aus dem Cache bereitgestellt, nachdem eine Anfrage an den Ursprung gesendet wurde, um zu überprüfen, ob das zwischengespeicherte Objekt noch gültig ist. In diesem Fall CloudFront wurde nicht das vollständige Objekt vom Ursprung abgerufen.

cdn-cache-miss

CloudFront hat die Antwort aus dem Cache nicht bereitgestellt. In diesem Fall wurde das vollständige Objekt vom Ursprung CloudFront angefordert, bevor die Antwort zurückgegeben wurde.

cdn-pop

Enthält einen Wert, der beschreibt, welcher CloudFront Point of Presence (POP) die Anfrage bearbeitet hat.

cdn-rid

Enthält einen Wert mit dem CloudFront eindeutigen Bezeichner für die Anforderung. Sie können diese Anforderungskennung (Request Identifier, RID) bei der Fehlerbehebung mit dem Support verwenden.

cdn-hit-layer

Diese Metrik ist vorhanden, wenn CloudFront eine Antwort aus dem Cache bereitgestellt wird, ohne eine Anfrage an den Ursprung zu stellen. Sie enthält einen der folgenden Werte:

  • EDGE — CloudFront hat die zwischengespeicherte Antwort von einem POP-Standort aus bereitgestellt.

  • REC — CloudFront hat die zwischengespeicherte Antwort von einem regionalen Edge-Cache-Standort (REC) bereitgestellt.

  • Origin Shield — CloudFront hat die zwischengespeicherte Antwort des REC bereitgestellt, der als Origin Shield fungiert.

cdn-upstream-layer

Wenn CloudFront das vollständige Objekt vom Ursprung angefordert wird, ist diese Metrik vorhanden und enthält einen der folgenden Werte:

  • EDGE – Ein POP-Standort hat die Anforderung direkt an den Ursprung gesendet.

  • REC – Ein REC-Standort hat die Anforderung direkt an den Ursprung gesendet.

  • Origin Shield – Der REC, der als Origin Shield fungiert, hat die Anforderung direkt an den Ursprung gesendet.

cdn-upstream-dns

Enthält einen Wert mit der Anzahl der Millisekunden, die für das Abrufen des DNS-Datensatzes für den Ursprung aufgewendet wurden. Ein Wert von Null (0) gibt an, dass ein zwischengespeichertes DNS-Ergebnis CloudFront verwendet oder eine bestehende Verbindung wiederverwendet wurde.

cdn-upstream-connect

Enthält einen Wert mit der Anzahl der Millisekunden zwischen dem Abschluss der DNS-Anforderung des Ursprungs und dem Abschluss einer TCP-Verbindung (und ggf. TLS-Verbindung) zum Ursprung. Ein Wert von Null (0) gibt an, dass eine bestehende Verbindung CloudFront wiederverwendet wurde.

cdn-upstream-fbl

Enthält einen Wert mit der Anzahl der Millisekunden zwischen dem Abschluss der HTTP-Anforderung des Ursprungs und dem Zeitpunkt, an dem das erste Byte in der Antwort vom Ursprung empfangen wird (Latenz des ersten Byte).

cdn-downstream-fbl

Enthält einen Wert mit der Anzahl der Millisekunden zwischen dem Zeitpunkt, an dem der Edge-Standort die Anforderung vollständig empfangen hat, und dem Zeitpunkt, an dem das erste Byte der Antwort an den Viewer gesendet wird.

Server-Timing Beispiele für Header

Im Folgenden finden Sie Beispiele für einen Server-Timing Header, den ein Viewer möglicherweise empfängt, CloudFront wenn die Server-Timing Header-Einstellung aktiviert ist.

Beispiel– Cache-Fehler

Das folgende Beispiel zeigt einen Server-Timing Header, den ein Viewer möglicherweise erhält, wenn sich das angeforderte Objekt nicht im CloudFront Cache befindet.

Server-Timing: cdn-upstream-layer;desc="EDGE",cdn-upstream-dns;dur=0,cdn-upstream-connect;dur=114,cdn-upstream-fbl;dur=177,cdn-cache-miss,cdn-pop;desc="PHX50-C2",cdn-rid;desc="yNPsyYn7skvTzwWkq3Wcc8Nj_foxUjQUe9H1ifslzWhb0w7aLbFvGg==",cdn-downstream-fbl;dur=436

Dieser Server-Timing-Header gibt Folgendes an:

  • Die Quellanforderung wurde von einem POP-Standort ( CloudFront Point of Presence) aus gesendet (cdn-upstream-layer;desc="EDGE").

  • CloudFront verwendete ein zwischengespeichertes DNS-Ergebnis für den Ursprung (cdn-upstream-dns;dur=0).

  • Es dauerte 114 Millisekunden, CloudFront bis die TCP-Verbindung (und TLS, falls zutreffend) zum Ursprung () hergestellt war. cdn-upstream-connect;dur=114

  • Nach Abschluss der Anfrage () dauerte es 177 Millisekunden, CloudFront bis das erste Byte der Antwort vom Ursprung empfangen wurde. cdn-upstream-fbl;dur=177

  • Das angeforderte Objekt befand sich nicht im CloudFront Cache (). cdn-cache-miss

  • Die Anforderung wurde an dem durch den Code PHX50-C2 identifizierten Edge-Standort empfangen (cdn-pop;desc="PHX50-C2").

  • Die CloudFront eindeutige ID für diese Anfrage war yNPsyYn7skvTzwWkq3Wcc8Nj_foxUjQUe9H1ifslzWhb0w7aLbFvGg== (cdn-rid;desc="yNPsyYn7skvTzwWkq3Wcc8Nj_foxUjQUe9H1ifslzWhb0w7aLbFvGg==").

  • Nach Erhalt der Viewer-Anfrage () dauerte es 436 Millisekunden, bis das erste Byte der Antwort an den Betrachter gesendet wurde. CloudFront cdn-downstream-fbl;dur=436

Beispiel– Cache-Treffer

Das folgende Beispiel zeigt einen Server-Timing Header, den ein Viewer möglicherweise erhält, wenn sich das angeforderte Objekt im Cache befindet. CloudFront 

Server-Timing: cdn-cache-hit,cdn-pop;desc="SEA19-C1",cdn-rid;desc="nQBz4aJU2kP9iC3KHEq7vFxfMozu-VYBwGzkW9diOpeVc7xsrLKj-g==",cdn-hit-layer;desc="REC",cdn-downstream-fbl;dur=137

Dieser Server-Timing-Header gibt Folgendes an:

  • Das angeforderte Objekt war im Cache vorhanden (cdn-cache-hit).

  • Die Anforderung wurde an dem durch den Code SEA19-C1 identifizierten Edge-Standort empfangen (cdn-pop;desc="SEA19-C1").

  • Die CloudFront eindeutige ID für diese Anfrage war nQBz4aJU2kP9iC3KHEq7vFxfMozu-VYBwGzkW9diOpeVc7xsrLKj-g== (cdn-rid;desc="nQBz4aJU2kP9iC3KHEq7vFxfMozu-VYBwGzkW9diOpeVc7xsrLKj-g==").

  • Das angeforderte Objekt wurde an einem REC-Standort (regionaler Edge-Cache) zwischengespeichert (cdn-hit-layer;desc="REC").

  • Nach Erhalt der Viewer-Anfrage () dauerte es 137 Millisekunden, bis das erste Byte der Antwort an den Zuschauer gesendet wurde. CloudFront cdn-downstream-fbl;dur=137