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 Antwort-Header-Richtlinie 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.
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 (
true
oderfalse
), die bestimmt, ob derAccess-Control-Allow-Credentials
Header in Antworten auf CORS-Anfragen CloudFront hinzugefügt wird. Wenn diese Einstellung auf gesetzt isttrue
, wird derAccess-Control-Allow-Credentials: true
Header in Antworten auf CORS-Anfragen CloudFront hinzugefügt. 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 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 PlatzhalterzeichensBeispiel Ü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 sindGET
,DELETE
,HEAD
,OPTIONS
,PATCH
,POST
,PUT
undALL
.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
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. Beispiele finden Sie in der folgenden Tabelle:Anmerkung
Das Platzhalterzeichen (
*
) ist als äußerster linker Teil der Domain (*.example.org
) zulässig.Das Platzhalterzeichen (
*
) ist an den folgenden Stellen nicht zulässig:-
Top-Level-Domains (
example.*
) -
Rechts neben Sub-Domains (
test.*.example.org
) -
Innerhalb von Begriffen (
exa*mple.org)
Beispiele für die gültige Verwendung des Platzhalterzeichens sind in der folgenden Tabelle aufgeführt:
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 Antwort der CORS-Header in der Richtlinie 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
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 zur Inhaltssicherheitsrichtlinie an, die als Werte für den
Content-Security-Policy
Antwort-Header 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-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 sindno-referrer
,no-referrer-when-downgrade
,origin
,origin-when-cross-origin
,same-origin
,strict-origin
,strict-origin-when-cross-origin
undunsafe-url
.Weitere Informationen zu diesem Header und diesen Richtlinien finden Sie unter Referrer-Policy
in den MDN-Webdokumenten. - Strict-Transport-Security
-
Gibt die Direktiven 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 (
true
oderfalse
) fürpreload
, die bestimmt, ob CloudFront diepreload
Direktive in den Wert dieses Headers aufgenommen wird -
Eine boolesche Einstellung (
true
oderfalse
) fürincludeSubDomains
, die bestimmt, ob dieincludeSubDomains
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 (
true
oderfalse
), die bestimmt, ob der Header zu Antworten CloudFront hinzugefügt wirdX-Content-Type-Options
. Wenn diese Einstellung aktiviert isttrue
, wird derX-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 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
Antwort-Header CloudFront verwendet wird. Gültige Werte für diese Einstellung sindDENY
oderSAMEORIGIN
.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
-Einstellung0
(deaktiviert XSS-Filterung) oder1
(aktiviert XSS-Filterung) -
Eine boolesche Einstellung (
true
oderfalse
) fürblock
, die bestimmt, ob diemode=block
Direktive CloudFront in den Wert für diesen Header aufgenommen wird -
Ein Berichts-URI, der bestimmt, ob CloudFront die
report=
Direktive in den Wert für diesen Header aufgenommen wirdreporting URI
Sie können
true
fürblock
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-Protectionin den MDN-Webdokumenten. -
- Origin override (Ursprungsüberschreibung)
-
Jede dieser Einstellungen für Sicherheitsheader enthält eine boolesche Einstellung (
true
oderfalse
), 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 (CORS-Header, Sicherheitsheader, benutzerdefinierte Header usw.). Wenn Sie einen Header angeben, der entfernt werden soll, aber denselben Header auch in einem anderen Abschnitt der Richtlinie hinzufügen, wird der Header in die Antworten aufgenommen, die an CloudFront 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 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 Server-Timing
Header-Einstellung, um den Server-Timing
Header in HTTP-Antworten zu aktivieren, von denen gesendet wird CloudFront. Sie können diesen Header verwenden, um Metriken anzuzeigen, 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).
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 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 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 Samplerate auf Null (0) gesetzt ist, wird der Antwort der Server-Timing
Header 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 Metriksätzen 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 je nach Art der Anfrage und Antwort nur einige dieser Metriken 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 (Request Identifier, RID) bei der Fehlerbehebung mit dem AWS 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-Speicherort bereitgestellt.
-
REC — CloudFront hat die zwischengespeicherte Antwort von einem regionalen Edge-Cache-Standort (REC) bereitgestellt.
-
Origin Shield — CloudFront hat die zwischengespeicherte Antwort von der REC bereitgestellt, die 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 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 CloudFront ein zwischengespeichertes DNS-Ergebnis 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. 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 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 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 POP-Standort ( CloudFront Point of Presence) (
cdn-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 TCP-Verbindung (und gegebenenfalls TLS) 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 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 Betrachter gesendet wurde. CloudFront
cdn-downstream-fbl;dur=137