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 mit einer Antwort-Header-Richtlinie die HTTP-Header angeben, die Amazon CloudFront in Antworten entfernt oder hinzufügt, die an Viewer gesendet werden. 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.
Themen
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
- Access-Control-Allow-Credentials
-
Dies ist eine boolesche Einstellung (
trueoderfalse), die festlegt, ob CloudFront denAccess-Control-Allow-Credentials-Header in Antworten auf CORS-Anforderungen hinzufügt. Wenn diese Einstellungtrueist, fügt CloudFront den HeaderAccess-Control-Allow-Credentials: truein Antworten auf CORS-Anforderungen hinzu. Andernfalls fügt CloudFront diesen Header den Antworten nicht hinzu. - Access-Control-Allow-Headers
-
Gibt die Header-Namen an, die CloudFront als Werte für den
Access-Control-Allow-Headers-Header in Antworten auf CORS-Preflight-Anforderungen verwendet. 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-testx-amz-x-amzx-*-amzx-test-amzx--amz*Alle Header außer AuthorizationAuthorization - Access-Control-Allow-Methods
-
Gibt die HTTP-Methoden an, die CloudFront als Werte für den
Access-Control-Allow-Methods-Header in Antworten auf CORS-Preflight-Anforderungen verwendet. Gültige Werte sindGET,DELETE,HEAD,OPTIONS,PATCH,POST,PUTundALL.ALList ein spezieller Wert, der alle aufgelisteten HTTP-Methoden enthält. - Access-Control-Allow-Origin
-
Gibt die Werte an, die CloudFront im
Access-Control-Allow-Origin-Antwort-Header verwenden kann. 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-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.orghttp://www.example.orghttp://test.example.orghttps://test.example.orghttps://test.example.org:123http://test.example.org:123*.example.orgtest.example.orgtest.test.example.org.example.orghttp://test.example.orghttps://test.example.orghttp://test.example.org:123https://test.example.org:123example.orghttp://example.orghttps://example.orghttp://example.orghttps://example.orghttp://example.org:123http://example.org:*http://example.org:123http://example.orghttp://example.org:1*3http://example.org:123http://example.org:1893http://example.org:13*.example.org:1*test.example.org:123 -
- Access-Control-Expose-Headers
-
Gibt die Header-Namen an, die CloudFront als Werte für den
Access-Control-Expose-Headers-Header in Antworten auf CORS-Anforderungen verwendet. Zu den gültigen Werten für diese Einstellung gehören HTTP-Header-Namen oder das Platzhalterzeichen (*). - Access-Control-Max-Age
-
Anzahl der Sekunden, die CloudFront als Wert für den
Access-Control-Max-Age-Header in Antworten auf CORS-Preflight-Anforderungen verwendet. - Origin override (Ursprungsüberschreibung)
-
Eine boolesche Einstellung, die festlegt, wie sich CloudFront verhält, wenn die Antwort vom Ursprung einen der CORS-Header enthält, die ebenfalls in der Richtlinie enthalten sind.
-
Wenn sie auf
truegesetzt ist und die Ursprungsantwort einen CORS-Header enthält, der ebenfalls in der Richtlinie enthalten ist, fügt CloudFront den CORS-Header in der Richtlinie der Antwort hinzu. CloudFront sendet diese Antwort dann an den Viewer. Der vom Ursprung empfangene Header wird von CloudFront ignoriert. -
Wenn sie auf
falsegesetzt ist und die Ursprungsantwort einen CORS-Header enthält (unabhängig davon, ob sich der CORS-Header in der Richtlinie befindet), fügt CloudFront den vom Ursprung empfangenen CORS-Header in der Antwort hinzu. CloudFront fügt der Antwort, die an den Viewer 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 Inhaltssicherheitsrichtlinien an, die CloudFront als Werte für den
Content-Security-Policy-Antwort-Header verwendet.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-Richtlinie
-
Gibt die Referrer-Richtlinie an, die CloudFront als Wert für den
Referrer-Policy-Antwort-Header verwendet. Gültige Werte für diese Einstellung sindno-referrer,no-referrer-when-downgrade,origin,origin-when-cross-origin,same-origin,strict-origin,strict-origin-when-cross-originundunsafe-url.Weitere Informationen zu diesem Header und diesen Richtlinien finden Sie unter Referrer-Policy
in den MDN-Webdokumenten. - Strict-Transport-Security
-
Gibt die Richtlinien und Einstellungen an, die CloudFront als Wert für den
Strict-Transport-Security-Antwort-Header verwendet. Für diese Einstellung geben Sie separat Folgendes an:-
Anzahl der Sekunden, die CloudFront als Wert für die
max-age-Richtlinie dieses Headers verwendet -
Eine boolesche Einstellung (
trueoderfalse) fürpreload, die festlegt, ob CloudFront diepreload-Richtlinie im Wert dieses Headers hinzufügt -
Eine boolesche Einstellung (
trueoderfalse) fürincludeSubDomains, die festlegt, ob CloudFront dieincludeSubDomains-Richtlinie im Wert dieses Headers hinzufügt
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 festlegt, ob CloudFront Antworten denX-Content-Type-Options-Header hinzufügt. Wenn diese Einstellungtrueist, fügt CloudFront denX-Content-Type-Options: nosniff-Header zu Antworten hinzu. Andernfalls fügt CloudFront diesen Header nicht hinzu.Weitere Informationen zu diesem Header finden Sie unter X-Content-Type-Options
in den MDN-Webdokumenten. - X-Frame-Options
-
Gibt die Richtlinie an, die CloudFront als Wert für den
X-Frame-Options-Antwort-Header verwendet. Gültige Werte für diese Einstellung sindDENYoderSAMEORIGIN.Weitere Informationen zu diesem Header und diesen Richtlinien finden Sie unter X-Frame-Options
in den MDN-Webdokumenten. - X-XSS-Protection
-
Gibt die Richtlinien und Einstellungen an, die CloudFront als Wert für den
X-XSS-Protection-Antwort-Header verwendet. Für diese Einstellung geben Sie separat Folgendes an:-
Die
X-XSS-Protection-Einstellung0(deaktiviert XSS-Filterung) oder1(aktiviert XSS-Filterung) -
Eine boolesche Einstellung (
trueoderfalse) fürblock, die festlegt, ob CloudFront diemode=block-Richtlinie im Wert für diesen Header hinzufügt -
Berichts-URI, der bestimmt, ob CloudFront die
report=-Richtlinie im Wert dieses Headers hinzufügtreporting URI
Sie können
truefürblockoder 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-Protectionin den MDN-Webdokumenten. -
- Origin override (Ursprungsüberschreibung)
-
Jede dieser Einstellungen für Sicherheits-Header enthält eine boolesche Einstellung (
trueoderfalse), die festlegt, wie sich CloudFront verhält, wenn die Antwort vom Ursprung diesen Header enthält.Wenn diese Einstellung
trueist und die Ursprungsantwort den Header enthält, fügt CloudFront den Header in der Richtlinie der Antwort hinzu, die an den Viewer gesendet wird. Der vom Ursprung empfangene Header wird dabei ignoriert.Wenn diese Einstellung
falseist und die Ursprungsantwort den Header enthält, fügt CloudFront den vom Ursprung empfangenen Header in der Antwort hinzu, die an den Viewer gesendet wird.Wenn die Ursprungsantwort den Header nicht enthält, fügt CloudFront den Header in der Richtlinie der Antwort hinzu, die an den Viewer gesendet wird. Dies erfolgt unabhängig davon, ob diese Einstellung auf
trueoderfalsefestgelegt ist.
Benutzerdefinierte Header
Mit benutzerdefinierten Header-Einstellungen können Sie benutzerdefinierte HTTP-Header in einer Antwort-Header-Richtlinie hinzufügen und konfigurieren. CloudFront fügt diese Header jeder Antwort hinzu, die an die Viewer zurückgegeben werden. 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 CloudFront einen Antwort-Header ohne Wert hinzufügen kann.
Jeder benutzerdefinierte Header verfügt zudem über eine eigene Einstellung für Origin override (Ursprungsüberschreibung):
-
Wenn diese Einstellung
trueist und die Ursprungsantwort den benutzerdefinierten Header enthält, der in der Richtlinie enthalten ist, fügt CloudFront den benutzerdefinierten Header in der Richtlinie der Antwort hinzu, die an den Viewer gesendet wird. Der vom Ursprung empfangene Header wird dabei ignoriert. -
Wenn diese Einstellung
falseist und die Ursprungsantwort den benutzerdefinierten Header enthält, der in der Richtlinie enthalten ist, fügt CloudFront den vom Ursprung empfangenen benutzerdefinierten Header in der Antwort hinzu, die an den Viewer gesendet wird. -
Wenn die Ursprungsantwort nicht den benutzerdefinierten Header enthält, der in der Richtlinie enthalten ist, fügt CloudFront den benutzerdefinierten Header in der Richtlinie der Antwort hinzu, die an den Viewer gesendet wird. Dies erfolgt unabhängig davon, ob diese Einstellung auf
trueoderfalsefestgelegt ist.
Entfernen von Headern
Sie können Header angeben, die CloudFront aus den vom Ursprung erhaltenen Antworten entfernen soll, damit die Header nicht in den Antworten enthalten sind, die CloudFront an Viewer sendet. CloudFront entfernt die Header aus jeder Antwort, die es an Viewer sendet, unabhängig davon, ob die Objekte aus dem Cache von CloudFront oder vom Ursprung bereitgestellt werden. Sie können beispielsweise Header entfernen, die für Browser nicht von Nutzen sind, z. B. X-Powered-By oder Vary, sodass CloudFront diese Header aus den Antworten entfernt, die es an Viewer sendet.
Wenn Sie mithilfe einer Antwort-Header-Richtlinie die zu entfernenden Header angeben, entfernt CloudFront zuerst die Header und fügt dann alle Header hinzu, die in anderen Abschnitten der Antwort-Header-Richtlinie angegeben sind (CORS-Header, Sicherheits-Header, benutzerdefinierte Header usw.). Wenn Sie einen Header angeben, der entfernt werden soll, aber denselben Header in einem anderen Abschnitt der Richtlinie hinzufügen, nimmt CloudFront den Header in die Antworten auf, die es an Viewer sendet.
Anmerkung
Sie können eine Antwort-Header-Richtlinie verwenden, um die Server- und Date-Header zu entfernen, die CloudFront vom Ursprung erhalten hat, sodass diese Header (wie vom Ursprung erhalten) nicht in die Antworten aufgenommen werden, die CloudFront an Viewer sendet. Wenn Sie dies tun, fügt CloudFront den Antworten, die es an Viewer sendet, allerdings seine eigene Version dieser Header hinzu. Der Wert für den Server-Header, den CloudFront hinzufügt, lautet CloudFront.
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-Cache -
X-Edge-.* -
X-Forwarded-Proto -
X-Real-Ip
Server-Timing-Header
Verwenden Sie die Header-Einstellung Server-Timing, um den Header Server-Timing in von CloudFront gesendeten HTTP-Antworten zu aktivieren. Sie können diesen Header verwenden, um Metriken anzuzeigen, mit denen Sie Erkenntnisse über das Verhalten und die Leistung von CloudFront und Ihrem Ursprung gewinnen können. 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 im Header Server-Timing können Ihnen helfen, Probleme zu beheben oder die Effizienz Ihrer CloudFront- oder Ursprungskonfiguration zu testen.
Weitere Informationen zum Verwenden von Header Server-Timing 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).
Themen
Abtastrate und Pragma-Anforderungs-Header
Wenn Sie den Header Server-Timing in einer Antwort-Header-Richtlinie aktivieren, geben Sie auch die Abtastrate an. Die Abtastrate ist eine Zahl von 0 bis 100 (jeweils einschließlich), die den Prozentsatz der Antworten angibt, denen CloudFront den Header Server-Timing hinzufügen soll. Wenn als Abtastrate 100 festgelegt wird, fügt CloudFront den Header Server-Timing der HTTP-Antwort für jede Anforderung hinzu, die dem Cache-Verhalten entspricht, an das die Antwort-Header-Richtlinie angefügt ist. Wenn 50 festgelegt wird, fügt CloudFront den Header 50 % der Antworten für Anforderungen hinzu, die dem Cache-Verhalten entsprechen. Sie können als Abtastrate eine beliebige Zahl von 0 bis 100 mit bis zu vier Dezimalstellen festlegen.
Wenn als Abtastrate eine Zahl unter 100 festgelegt ist, können Sie nicht steuern, welchen Antworten CloudFront den Header Server-Timing hinzufügt. Sie geben lediglich den Prozentsatz an. 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 als Abtastrate Null (0) festgelegt ist, fügt CloudFront den Header Server-Timing der Antwort hinzu, wenn die Anforderung den Header Pragma: server-timing enthält.
Server-Timing-Header vom Ursprung
Wenn ein Cache fehlt und CloudFront die Anforderung an den Ursprung weiterleitet, kann der Ursprung einen Server-Timing-Header in seiner Antwort an CloudFront enthalten. In diesem Fall fügt CloudFront die Metriken zum Server-Timing-Header hinzu, den es vom Ursprung erhalten hat. Die Antwort, die CloudFront an den Viewer sendet, enthält einen einzigen Server-Timing-Header, der den aus dem Ursprung stammenden Wert enthält sowie die Metriken, die CloudFront hinzugefügt hat. Der Header-Wert vom Ursprung kann am Ende oder zwischen zwei Metrikengruppen liegen, die CloudFront dem Header hinzufügt.
Bei einem Cache-Treffer enthält die Antwort, die CloudFront an den Viewer sendet, einen einzigen Server-Timing-Header, der nur die CloudFront-Metriken im Header-Wert enthält (der Wert vom Ursprung ist nicht enthalten).
Metriken des Server-Timing-Headers
Wenn CloudFront einer HTTP-Antwort den Header Server-Timing hinzufügt, enthält der Wert des Headers eine oder mehrere Metriken, mit denen Sie Erkenntnisse über das Verhalten und die Leistung von CloudFront und Ihrem 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 Anforderung und der Antwort über 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 ohne eine Anforderung an den Ursprung eine Antwort aus dem Cache bereitgestellt.
- cdn-cache-refresh
-
CloudFront hat eine Antwort aus dem Cache bereitgestellt, nachdem eine Anforderung an den Ursprung gesendet wurde, um zu überprüfen, ob das zwischengespeicherte Objekt noch gültig ist. In diesem Fall hat CloudFront nicht das vollständige Objekt vom Ursprung abgerufen.
- cdn-cache-miss
-
CloudFront hat die Antwort aus dem Cache nicht bereitgestellt. In diesem Fall hat CloudFront das vollständige Objekt vom Ursprung angefordert, bevor die Antwort zurückgegeben wurde.
- cdn-pop
-
Enthält einen Wert, der beschreibt, welcher CloudFront-Point-of-Presence (POP) die Anforderung verarbeitet hat.
- cdn-rid
-
Enthält einen Wert mit der eindeutigen CloudFront-Kennung 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 ohne Anforderung an den Ursprung eine Antwort aus dem Cache bereitstellt. 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) aus bereitgestellt.
-
Origin Shield – CloudFront hat die zwischengespeicherte Antwort vom REC bereitgestellt, der als Origin Shield fungiert.
-
- cdn-upstream-layer
-
Wenn CloudFront das vollständige Objekt vom Ursprung anfordert, 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. Der Wert Null (0) zeigt an, dass CloudFront ein zwischengespeichertes DNS-Ergebnis verwendet oder eine vorhandene Verbindung wiederverwendet hat.
- 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. Der Wert Null (0) zeigt an, dass CloudFront eine vorhandene Verbindung wiederverwendet hat.
- 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.
Beispiele für Server-Timing-Header
Im Folgenden finden Sie Beispiele für einen Server-Timing-Header, den ein Viewer möglicherweise von CloudFront empfängt, wenn die Header-Einstellung Server-Timing aktiviert ist.
Beispiel – Cache-Fehler
Das folgende Beispiel zeigt einen Server-Timing-Header, den ein Viewer möglicherweise empfängt, 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=436Dieser Server-Timing-Header gibt Folgendes an:
-
Die Ursprungsanforderung wurde von einem CloudFront-POP (Point of Presence)-Standort (
cdn-upstream-layer;desc="EDGE") gesendet. -
CloudFront hat ein zwischengespeichertes DNS-Ergebnis für den Ursprung verwendet (
cdn-upstream-dns;dur=0). -
Es hat 114 Millisekunden gedauert, bis CloudFront die TCP-Verbindung (und ggf. TLS-Verbindung) zum Ursprung abgeschlossen hat (
cdn-upstream-connect;dur=114). -
Es hat 177 Millisekunden gedauert, bis CloudFront das erste Byte der Antwort vom Ursprung erhalten hat, nachdem die Anfrage abgeschlossen wurde (
cdn-upstream-fbl;dur=177). -
Das angeforderte Objekt war nicht im Cache von CloudFront enthalten (
cdn-cache-miss). -
Die Anforderung wurde an dem durch den Code
PHX50-C2identifizierten Edge-Standort empfangen (cdn-pop;desc="PHX50-C2"). -
Die eindeutige CloudFront-ID für diese Anfrage lautete
yNPsyYn7skvTzwWkq3Wcc8Nj_foxUjQUe9H1ifslzWhb0w7aLbFvGg==(cdn-rid;desc="yNPsyYn7skvTzwWkq3Wcc8Nj_foxUjQUe9H1ifslzWhb0w7aLbFvGg=="). -
Es hat 436 Millisekunden gedauert, bis CloudFront das erste Byte der Antwort an den Viewer gesendet hat, nachdem die Viewer-Anfrage empfangen wurde (
cdn-downstream-fbl;dur=436).
Beispiel – Cache-Treffer
Das folgende Beispiel zeigt einen Server-Timing-Header, den ein Viewer möglicherweise empfängt, wenn sich das angeforderte Objekt im CloudFront-Cache befindet.
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=137Dieser 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-C1identifizierten Edge-Standort empfangen (cdn-pop;desc="SEA19-C1"). -
Die eindeutige CloudFront-ID für diese Anfrage lautete
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"). -
Es hat 137 Millisekunden gedauert, bis CloudFront das erste Byte der Antwort an den Viewer gesendet hat, nachdem die Viewer-Anfrage empfangen wurde (
cdn-downstream-fbl;dur=137).