Verstehen Sie die Richtlinien für Antwort-Header - Amazon CloudFront
Richtliniendetails (Metadaten)CORSHeaderSicherheits-HeaderBenutzerdefinierte HeaderEntfernen von HeadernServer-Timing-Header

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.

Verstehen Sie die Richtlinien für Antwort-Header

Sie können eine Richtlinie für Antwort-Header verwenden, um die HTTP Header anzugeben, die Amazon CloudFront entfernt oder zu Antworten hinzufügt, die es an Zuschauer sendet. 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.

CORSHeader

Mit den ursprungsübergreifenden Einstellungen für die gemeinsame Nutzung von Ressourcen (CORS) können Sie CORS Header in einer Response-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 einzelnen Headern und dazu, wie sie für reale CORS Anfragen und Antworten verwendet werden, finden Sie in den MDN Webdokumenten unter Cross-Origin Resource Sharing und in der Protokollspezifikation. CORS

Access-Control-Allow-Credentials

Dies ist eine boolesche Einstellung (trueoderfalse), die bestimmt, ob der Header in Antworten auf Anfragen CloudFront hinzugefügt wirdAccess-Control-Allow-Credentials. CORS Wenn diese Einstellung auf gesetzt isttrue, wird der Access-Control-Allow-Credentials: true Header in Antworten auf Anfragen CloudFront hinzugefügt. CORS Andernfalls wird dieser Header CloudFront nicht zu 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 angibt, dass alle Header zulässig sind.

Anmerkung

Die Authorization Kopfzeile 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 GETDELETE,HEAD,OPTIONS,PATCH, POSTPUT, undALL. ALList ein spezieller Wert, der alle aufgelisteten HTTP Methoden umfasst.

Access-Control-Allow-Origin

Gibt die Werte an, die im Access-Control-Allow-Origin Antwort-Header 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 Unterdomäne ganz links () zulässig. *.example.org

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

    • Top-Level-Domains (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

http://test.example.org:123

https://test.example.org

https://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 in 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 diese Option auf gesetzt ist true und die ursprüngliche Antwort einen CORS Header enthält, der auch in der Richtlinie enthalten ist, wird der CORS Header in der Richtlinie zur Antwort CloudFront hinzugefügt. CloudFront sendet diese Antwort dann an den Betrachter. CloudFront ignoriert den Header, den es vom Ursprung erhalten hat.

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

Sicherheits-Header

Sie können die Einstellungen für Sicherheitsheader verwenden, um mehrere sicherheitsrelevante HTTP Antwortheader in einer Antwortheader-Richtlinie hinzuzufügen und zu konfigurieren.

Diese Liste beschreibt, wie Sie Einstellungen und gültige Werte in einer Antwort-Header-Richtlinie angeben können. Weitere Informationen zu den einzelnen Headern und dazu, wie sie in realen HTTP Antworten verwendet werden, finden Sie in den Links zu den Webdokumenten. MDN

Content-Security-Policy

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

Weitere Informationen zu diesem Header und zu gültigen Richtliniendirektiven finden Sie Content-Security-Policyin den MDN Webdokumenten.

Anmerkung

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

Referrer-Richtlinie

Gibt die Referrer-Richtliniendirektive an, die als Wert für den Referrer-Policy Antwort-Header 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 Direktiven finden Sie Referrer-Policyin den MDN Webdokumenten.

Strict-Transport-Security

Gibt die Direktiven und Einstellungen an, die als Wert für den Strict-Transport-Security Antwort-Header 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 Direktiven finden Sie Strict-Transport-Securityin den MDN Webdokumenten.

X-Content-Type-Options

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

Weitere Informationen zu diesem Header finden Sie X-Content-Type-Optionsin 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 Direktiven finden Sie X-Frame-Optionsin den MDN Webdokumenten.

X- XSS -Schutz

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

  • Eine X-XSS-Protection Einstellung von 0 (deaktiviert die XSS Filterung) oder 1 (aktiviert die XSS Filterung)

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

  • Ein BerichtURI, 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 Sie können einen Bericht angebenURI, aber Sie können nicht beide zusammen angeben. Weitere Informationen zu diesem Header und diesen Direktiven finden Sie X-XSS-Protectionin den MDN Webdokumenten.

Origin override (Ursprungsüberschreibung)

Jede dieser Sicherheitsheader-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 ursprüngliche Antwort den Header enthält, wird der Header in der Richtlinie der Antwort CloudFront hinzugefügt, die an den Betrachter gesendet wird. Der vom Ursprung empfangene Header wird dabei ignoriert.

Wenn diese Einstellung auf gesetzt ist false und die ursprüngliche Antwort den Header CloudFront enthält, wird der Header, den sie vom Ursprung erhalten hat, in die Antwort aufgenommen, die sie an den Betrachter sendet.

Wenn die ursprüngliche Antwort den Header nicht enthält, wird der Header in der Richtlinie der Antwort CloudFront hinzugefügt, die an den Betrachter gesendet wird. 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 Antwort-Header-Richtlinie hinzuzufügen und zu konfigurieren. CloudFront fügt diese Header zu jeder Antwort hinzu, die es an die Zuschauer zurückgibt. 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 Antwort-Header 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 ursprüngliche Antwort den benutzerdefinierten Header enthält, der in der Richtlinie enthalten ist, wird der benutzerdefinierte Header in der Richtlinie der Antwort CloudFront hinzugefügt, die sie an den Betrachter sendet. Der vom Ursprung empfangene Header wird dabei ignoriert.

  • Wenn diese Einstellung aktiviert ist false und die ursprüngliche Antwort den benutzerdefinierten Header enthält, der in der Richtlinie enthalten ist, CloudFront wird der benutzerdefinierte Header, den sie vom Ursprung erhalten hat, in die Antwort aufgenommen, die sie an den Betrachter sendet.

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

Entfernen von Headern

Sie können Header angeben, die Sie aus den Antworten entfernen CloudFront möchten, die das System vom Absender erhält, sodass die Header nicht in den Antworten enthalten sind, die CloudFront an die Zuschauer gesendet werden. CloudFront entfernt die Header aus jeder Antwort, die es an Zuschauer sendet, unabhängig davon, ob die Objekte aus dem Cache oder aus dem CloudFront Ursprung bereitgestellt werden. Sie können beispielsweise Header entfernen, die für Browser nicht von Nutzen 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 Antwort-Header-Richtlinie Header angeben, die entfernt werden sollen, werden zuerst die Header CloudFront entfernt und dann alle Header hinzugefügt, die in anderen Abschnitten der Antwort-Header-Richtlinie angegeben sind (Header, Sicherheitsheader, CORS benutzerdefinierte Header usw.). Wenn Sie einen Header angeben, der entfernt werden soll, aber auch denselben Header in einem anderen Abschnitt der Richtlinie hinzufügen, wird der Header in die Antworten aufgenommen, die CloudFront an die Zuschauer gesendet werden.

Anmerkung

Sie können eine Richtlinie für Antwort-Header verwenden, um die Kopfzeilen Server und Date -Header zu entfernen, die vom Absender CloudFront empfangen wurden, sodass diese Header (wie sie vom Absender empfangen wurden) nicht in den Antworten enthalten sind, die an Zuschauer CloudFront gesendet werden. Wenn Sie das tun, CloudFront fügt es jedoch eine eigene Version dieser Header zu den Antworten hinzu, die es an Zuschauer sendet. Für den Server Header, der CloudFront etwas hinzufügt, 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 Header entfernen einer Antwort-Header-Richtlinie (ResponseHeadersPolicyRemoveHeadersConfigimAPI) 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-Cache

  • X-Edge-.*

  • X-Forwarded-Proto

  • X-Real-Ip

Server-Timing-Header

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 Messwerte einzusehen, die Ihnen helfen können, Einblicke in das Verhalten und die Leistung von CloudFront und über Ihre Herkunft 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 dir dabei helfen, Probleme zu beheben oder die Effizienz deiner Konfiguration CloudFront oder deiner Origin-Konfiguration 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 von 0 bis 100 (einschließlich), die den Prozentsatz der Antworten angibt, CloudFront zu denen Sie die Server-Timing Überschrift hinzufügen möchten. Wenn Sie die Samplerate auf 100 festlegen, wird der HTTP Antwort der Server-Timing Header für jede Anfrage CloudFront hinzugefügt, die dem Cache-Verhalten entspricht, an das die Antwort-Header-Richtlinie angehängt ist. Wenn Sie den Wert auf 50 setzen, wird der Header zu 50% der Antworten für Anfragen CloudFront hinzugefügt, die dem Cache-Verhalten entsprechen. Sie können als Abtastrate eine beliebige Zahl von 0 bis 100 mit bis zu vier Dezimalstellen festlegen.

Wenn die Samplerate auf eine Zahl unter 100 eingestellt ist, können Sie nicht kontrollieren, zu welcher Antwort der Server-Timing Header CloudFront hinzugefügt wird, sondern nur zu welchem Prozentsatz. Sie können jedoch den Pragma Header mit einem Wert auf zu server-timing einer HTTP Anfrage hinzufügen, um den Server-Timing Header in der Antwort auf diese Anfrage zu erhalten. 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 der 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 CloudFront die Anfrage an den Ursprung weitergeleitet wird, kann 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 Betrachter gesendet wird, enthält einen einzigen Server-Timing Header, der den Wert enthält, der vom Ursprung stammt, und die CloudFront hinzugefügten Metriken. Der Header-Wert aus dem Ursprung kann sich am Ende oder zwischen zwei Gruppen von Metriken befinden, 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 aus dem Ursprung ist nicht enthalten).

Metriken des Server-Timing-Headers

Wenn der Server-Timing Header zu einer HTTP Antwort CloudFront hinzugefügt wird, enthält der Wert des Headers eine oder mehrere Metriken, anhand derer Sie Erkenntnisse über das Verhalten und die Leistung von CloudFront und über Ihren Ursprung gewinnen können. 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, über die Sie weitergeleitet wurden 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 nach dem Senden einer Anfrage an den Ursprung eine Antwort aus dem Cache bereitgestellt, 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 nicht aus dem Cache 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 (RID) verwenden, um Probleme zu beheben mit Support

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 von dem bereitgestelltREC, der als Origin Shield fungiert.

cdn-upstream-layer

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

  • EDGE— Ein POP Standort hat die Anfrage direkt an den Ursprung gesendet.

  • REC— Ein REC Standort hat die Anfrage direkt an den Ursprung gesendet.

  • Origin Shield — DerREC, der als Origin Shield fungiert, hat die Anfrage 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 oder eine bestehende Verbindung CloudFront wiederverwendet wurde.

cdn-upstream-connect

Enthält einen Wert mit der Anzahl der Millisekunden zwischen dem Abschluss der ursprünglichen DNS Anfrage und dem Abschluss einer Verbindung zum Ursprung TCP (undTLS, falls zutreffend). Der Wert 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 ursprünglichen HTTP Anfrage und dem Empfang des ersten Bytes in der Antwort vom Ursprung (Latenz des ersten Bytes).

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.

Beispiele für Server-Timing-Header

Im Folgenden finden Sie Beispiele für einen Server-Timing Header, den ein Betrachter erhalten könnte, CloudFront wenn die Server-Timing Header-Einstellung aktiviert ist.

Beispiel – Cache-Fehler

Das folgende Beispiel zeigt einen Server-Timing Header, den ein Betrachter erhalten könnte, 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 ursprüngliche Anfrage wurde von einem CloudFront Point of Presence (POPcdn-upstream-layer;desc="EDGE") aus gesendet.

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

  • Es dauerte 114 Millisekunden, CloudFront bis die Verbindung TCP (undTLS, 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==").

  • Es dauerte 436 Millisekunden, CloudFront bis das erste Byte der Antwort an den Betrachter gesendet wurde, nachdem die Zuschaueranfrage () empfangen worden war. cdn-downstream-fbl;dur=436

Beispiel – Cache-Treffer

Das folgende Beispiel zeigt einen Server-Timing Header, den ein Betrachter erhalten könnte, 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 regionalen Edge-Cache-Standort (RECcdn-hit-layer;desc="REC") zwischengespeichert.

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