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.
# Verhalten von Anfragen und Antworten
In den folgenden Themen wird beschrieben, wie CloudFront mit Anfragen und Antworten umgegangen wird.
Sie erfahren, wie mit Amazon S3 oder benutzerdefinierten Ursprüngen CloudFront interagiert, mit verschiedenen HTTP-Methoden und -Headern umgeht, Statuscodes verarbeitet und Zwischenspeicherung und Fehlerantworten verwaltet.
**Topics**
+ [Wie werden HTTP CloudFront - und HTTPS-Anfragen verarbeitet](HTTPandHTTPSRequests.md)
+ [Verhalten von Anfragen und Antworten für Amazon-S3-Ursprünge](RequestAndResponseBehaviorS3Origin.md)
+ [Verhalten von Anfragen und Antworten für benutzerdefinierte Ursprungsserver](RequestAndResponseBehaviorCustomOrigin.md)
+ [Verhalten von Anfragen und Antworten für Ursprungsgruppen](RequestAndResponseBehaviorOriginGroups.md)
+ [Hinzufügen benutzerdefinierter Header zu Ursprungsanforderungen](add-origin-custom-headers.md)
+ [Wie CloudFront werden Teilanfragen für ein Objekt (BereichGETs) verarbeitet](RangeGETs.md)
+ [Wie CloudFront werden HTTP 3xx-Statuscodes von Ihrem Ursprung verarbeitet](http-3xx-status-codes.md)
+ [Wie CloudFront werden die HTTP-Statuscodes 4xx und 5xx von Ihrem Ursprung verarbeitet](HTTPStatusCodes.md)
+ [Erstellen von benutzerdefinierten Fehlerantworten](GeneratingCustomErrorResponses.md)
# Wie werden HTTP CloudFront - und HTTPS-Anfragen verarbeitet
CloudFront Akzeptiert für Amazon S3 S3-Ursprünge standardmäßig Anfragen sowohl im HTTP- als auch im HTTPS-Protokoll für Objekte in einer CloudFront Distribution. CloudFront leitet die Anfragen dann mit demselben Protokoll, in dem die Anfragen gestellt wurden, an Ihren Amazon S3 S3-Bucket weiter.
Bei benutzerdefinierten Ursprüngen können Sie beim Erstellen Ihrer Verteilung festlegen, wie CloudFront auf Ihren Ursprung zugreifen: nur HTTP oder entsprechend dem vom Betrachter verwendeten Protokoll. Weitere Informationen zum CloudFront Umgang mit HTTP- und HTTPS-Anfragen für benutzerdefinierte Ursprünge finden Sie unter[Protokolle](RequestAndResponseBehaviorCustomOrigin.md#RequestCustomProtocols).
Weitere Informationen dazu, wie Sie Ihre Verteilung so einschränken, dass Endbenutzer nur mit HTTPS auf Objekte zugreifen können, finden Sie unter [Verwenden Sie HTTPS mit CloudFront](using-https.md).
**Anmerkung**
Die Gebühr für HTTPS-Anfragen ist höher als die Gebühr für HTTP-Anfragen. Weitere Informationen zu den Abrechnungstarifen finden Sie unter [CloudFront Preise](https://aws.amazon.com/cloudfront/#pricing).
# Verhalten von Anfragen und Antworten für Amazon-S3-Ursprünge
In den folgenden Abschnitten erfahren Sie, wie Anfragen und Antworten CloudFront verarbeitet werden, wenn Sie Amazon S3 als Ausgangspunkt verwenden:
**Topics**
+ [Wie CloudFront verarbeitet und leitet Anfragen an Ihren Amazon S3 S3-Ursprung weiter](#RequestBehaviorS3Origin)
+ [So CloudFront werden Antworten von Ihrem Amazon S3 S3-Absender verarbeitet](#ResponseBehaviorS3Origin)
## Wie CloudFront verarbeitet und leitet Anfragen an Ihren Amazon S3 S3-Ursprung weiter
Erfahren Sie, wie Zuschaueranfragen CloudFront verarbeitet und die Anfragen an Ihren Amazon S3 S3-Ursprung weiterleitet.
**Contents**
+ [Cache-Dauer und Mindest-TTL](#RequestS3Caching)
+ [Client-IP-Adressen](#RequestS3IPAddresses)
+ [Bedingte GET-Anforderungen](#RequestS3ConditionalGETs)
+ [Cookies](#RequestS3Cookies)
+ [Cross-Origin Resource Sharing (CORS)](#RequestS3-cors)
+ [GET-Anfragen mit Anfragetext](#RequestS3-get-body)
+ [HTTP-Methoden](#RequestS3HTTPMethods)
+ [HTTP-Anforderungsheader, die CloudFront entfernt oder aktualisiert werden](#request-s3-removed-headers)
+ [Maximale Länge einer Anfrage und maximale Länge einer URL](#RequestS3MaxRequestStringLength)
+ [OCSP-Stapling](#request-s3-ocsp-stapling)
+ [Protokolle](#RequestS3Protocol)
+ [Abfragezeichenfolgen](#RequestS3QueryStrings)
+ [Timeout der Ursprungsverbindung und Verbindungsversuche zum Ursprung](#s3-origin-timeout-attempts)
+ [Ursprungs-Reaktions-Timeout](#RequestS3RequestTimeout)
+ [Gleichzeitige Anfragen für dasselbe Objekt (Zusammenfassung von Anfragen)](#request-s3-traffic-spikes)
### Cache-Dauer und Mindest-TTL
Um zu kontrollieren, wie lange Ihre Objekte in einem CloudFront Cache bleiben, bevor sie CloudFront eine weitere Anfrage an Ihren Ursprung weiterleiten, können Sie:
+ Ihren Ursprungsserver so konfigurieren, dass jedem Objekt ein `Cache-Control`- oder `Expires`-Header-Feld hinzugefügt wird
+ Geben Sie einen Wert für Minimale TTL in CloudFront Cache-Verhalten an.
+ Den Standardwert von 24 Stunden verwenden
Weitere Informationen finden Sie unter [Verwalten der Dauer, die Inhalte im Cache bleiben (Ablauf)](Expiration.md).
### Client-IP-Adressen
Wenn ein Viewer eine Anfrage an sendet CloudFront und keinen Anforderungsheader enthält, CloudFront ruft er die IP-Adresse des Betrachters aus der TCP-Verbindung ab, fügt einen `X-Forwarded-For` Header hinzu, der die IP-Adresse enthält, und leitet die Anfrage an den Ursprung weiter. `X-Forwarded-For` Wenn CloudFront z. B. die IP-Adresse `192.0.2.2` von der TCP-Verbindung abruft, wird der folgende Header an den Ursprungs-Server weitergeleitet:
`X-Forwarded-For: 192.0.2.2`
Wenn ein Betrachter eine Anfrage an den Anforderungsheader sendet CloudFront und diesen einschließt, CloudFront ruft er die IP-Adresse des Viewers aus der TCP-Verbindung ab, hängt sie an das Ende des `X-Forwarded-For` Headers an und leitet die Anfrage an den Ursprung weiter. `X-Forwarded-For` Wenn die Viewer-Anfrage beispielsweise die IP-Adresse der TCP-Verbindung enthält `X-Forwarded-For: 192.0.2.4,192.0.2.3` und diese CloudFront `192.0.2.2` abruft, leitet sie den folgenden Header an den Ursprung weiter:
`X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2`
**Anmerkung**
Der `X-Forwarded-For` Header enthält IPv4 Adressen (wie 192.0.2.44) und IPv6 Adressen (wie 2001:0 db 8:85 a3: :8a2e: 0370:7334).
### Bedingte GET-Anforderungen
Wenn eine Anfrage für ein Objekt CloudFront empfangen wird, das aus einem Edge-Cache abgelaufen ist, leitet es die Anfrage an den Amazon S3-Ursprung weiter, um die neueste Version des Objekts abzurufen oder um eine Bestätigung von Amazon S3 zu erhalten, dass der CloudFront Edge-Cache bereits über die neueste Version verfügt. Als Amazon S3 das Objekt ursprünglich an sendete CloudFront, enthielt es einen `ETag` Wert und einen `LastModified` Wert in der Antwort. Fügt in der neuen Anfrage CloudFront , die an Amazon S3 weitergeleitet wird, einen oder beide der folgenden Header CloudFront hinzu:
+ Einen `If-Match`- oder `If-None-Match`-Header mit dem `ETag`-Wert für die abgelaufene Version des Objekts
+ Einen `If-Modified-Since`-Header mit dem `LastModified`-Wert für die abgelaufene Version des Objekts
Amazon S3 verwendet diese Informationen, um festzustellen, ob das Objekt aktualisiert wurde und ob daher das gesamte Objekt an CloudFront oder nur ein HTTP-304-Statuscode (nicht geändert) zurückgegeben werden soll.
### Cookies
Amazon S3 verarbeitet keine Cookies. Wenn Sie ein Cache-Verhalten so konfigurieren, dass Cookies an einen Amazon S3-Ursprung weitergeleitet werden CloudFront , werden die Cookies weitergeleitet, Amazon S3 ignoriert sie jedoch. Alle zukünftigen Anfragen zu demselben Objekt werden mithilfe des im Cache vorhandenen Objekts bedient – unabhängig davon, ob Sie Änderungen an den Cookies vornehmen.
### Cross-Origin Resource Sharing (CORS)
Wenn Sie CloudFront die ursprungsübergreifenden Amazon S3-Einstellungen für die gemeinsame Nutzung von Ressourcen respektieren möchten, konfigurieren Sie die Konfiguration so, CloudFront dass ausgewählte Header an Amazon S3 weitergeleitet werden. Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Anforderungsheadern](header-caching.md).
### GET-Anfragen mit Anfragetext
Wenn eine `GET` Viewer-Anfrage einen Text enthält, wird der HTTP-Statuscode 403 (Forbidden) an den Betrachter CloudFront zurückgegeben.
### HTTP-Methoden
Wenn Sie so konfigurieren CloudFront , dass alle HTTP-Methoden verarbeitet werden, die es unterstützt, CloudFront akzeptiert es die folgenden Anfragen von Zuschauern und leitet sie an Ihren Amazon S3 S3-Ursprung weiter:
+ `DELETE`
+ `GET`
+ `HEAD`
+ `OPTIONS`
+ `PATCH`
+ `POST`
+ `PUT`
CloudFront speichert Antworten auf `GET` und `HEAD` Anfragen immer im Cache. Sie können auch so konfigurieren CloudFront , dass Antworten auf `OPTIONS` Anfragen zwischengespeichert werden. CloudFront speichert Antworten auf Anfragen, die die anderen Methoden verwenden, nicht im Cache.
Wenn Sie mehrteilige Uploads verwenden möchten, um Objekte zu einem Amazon S3 S3-Bucket hinzuzufügen, müssen Sie Ihrer Distribution eine CloudFront Origin-Zugriffskontrolle (OAC) hinzufügen und dem OAC die erforderlichen Berechtigungen erteilen. Weitere Informationen finden Sie unter [Beschränken des Zugriffs auf einen Amazon-S3-Ursprung](private-content-restricting-access-to-s3.md).
**Wichtig**
Wenn Sie so konfigurieren CloudFront , dass alle CloudFront unterstützten HTTP-Methoden akzeptiert und an Amazon S3 weitergeleitet werden, müssen Sie ein CloudFront OAC erstellen, um den Zugriff auf Ihre Amazon S3 S3-Inhalte einzuschränken und dem OAC die erforderlichen Berechtigungen zu erteilen. Wenn Sie beispielsweise so konfigurieren CloudFront , dass diese Methoden akzeptiert und weitergeleitet werden, weil Sie die `PUT` Methode verwenden möchten, müssen Sie die Amazon S3 S3-Bucket-Richtlinien so konfigurieren, dass `DELETE` Anfragen angemessen behandelt werden, sodass Zuschauer keine Ressourcen löschen können, die Sie nicht möchten. Weitere Informationen finden Sie unter [Beschränken des Zugriffs auf einen Amazon-S3-Ursprung](private-content-restricting-access-to-s3.md).
Informationen zu den von Amazon S3 unterstützten Operationen finden Sie in der [Amazon S3-Dokumentation](https://docs.aws.amazon.com/s3/index.html).
### HTTP-Anforderungsheader, die CloudFront entfernt oder aktualisiert werden
CloudFront entfernt oder aktualisiert einige Header, bevor Anfragen an Ihren Amazon S3 S3-Ursprung weitergeleitet werden. Für die meisten Header ist dieses Verhalten dasselbe wie für benutzerdefinierte Ursprünge. Eine vollständige Liste der HTTP-Anforderungsheader und deren Verarbeitung finden CloudFront Sie unter. [Header und CloudFront Verhalten von HTTP-Anfragen (benutzerdefiniert und Amazon S3 S3-Ursprünge)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior)
### Maximale Länge einer Anfrage und maximale Länge einer URL
Die maximale Länge einer Anfrage – einschließlich des Pfads, der Abfragezeichenfolge (falls vorhanden) und der Header – beträgt 20 480 Byte.
CloudFront konstruiert aus der Anfrage eine URL. Die maximale Länge dieser URL beträgt 8 192 Byte.
Wenn eine Anfrage oder eine URL die maximale Länge überschreitet, wird der HTTP-Statuscode 413 (Request Entity Too Large) an den Viewer CloudFront zurückgegeben und anschließend die TCP-Verbindung zum Viewer beendet.
### OCSP-Stapling
Wenn ein Betrachter eine HTTPS-Anfrage für ein Objekt sendet CloudFront oder der Betrachter bei der Zertifizierungsstelle (CA) bestätigen muss, dass das SSL-Zertifikat für die Domain nicht gesperrt wurde. OCSP-Stapling beschleunigt die Zertifikatsvalidierung, da CloudFront das Zertifikat validiert und die Antwort von der CA zwischengespeichert werden kann, sodass der Client das Zertifikat nicht direkt bei der CA validieren muss.
Die Leistungsverbesserung von OCSP-Stapling ist ausgeprägter, wenn CloudFront viele HTTPS-Anfragen für Objekte in derselben Domäne eingehen. Jeder Server an einem CloudFront -Edge-Standort muss eine separate Validierungsanfrage senden. Wenn viele HTTPS-Anfragen für dieselbe Domain eingehen, CloudFront erhält jeder Server am Edge-Standort bald eine Antwort von der CA, die er im SSL-Handshake an ein Paket heften kann. Wenn der Betrachter davon überzeugt ist, dass das Zertifikat gültig ist, CloudFront kann er das angeforderte Objekt bereitstellen. Wenn Ihre Verteilung nicht viel Datenverkehr an einem CloudFront -Edge-Standort generiert, werden neue Anfragen mit einer höheren Wahrscheinlichkeit an einen Server weitergeleitet, der das Zertifikat noch nicht bei der CA validiert hat. In diesem Fall führt der Betrachter den Validierungsschritt separat durch und der CloudFront Server stellt das Objekt bereit. Dieser CloudFront Server sendet auch eine Überprüfungsanfrage an die CA. Wenn er also das nächste Mal eine Anfrage erhält, die denselben Domainnamen enthält, erhält er eine Validierungsantwort von der CA.
### Protokolle
CloudFront leitet HTTP- oder HTTPS-Anfragen auf der Grundlage des Protokolls der Viewer-Anfrage, entweder HTTP oder HTTPS, an den Ursprungsserver weiter.
**Wichtig**
Wenn Ihr Amazon S3-Bucket als Website-Endpunkt konfiguriert ist, können Sie die Verwendung von HTTPS für die Kommunikation mit Ihrem Ursprung nicht konfigurieren CloudFront , da Amazon S3 in dieser Konfiguration keine HTTPS-Verbindungen unterstützt.
### Abfragezeichenfolgen
Sie können konfigurieren, ob CloudFront Abfragezeichenfolgenparameter an Ihren Amazon S3-Ursprung weitergeleitet werden. Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Abfragezeichenfolgeparametern](QueryStringParameters.md).
### Timeout der Ursprungsverbindung und Verbindungsversuche zum Ursprung
Das *Timeout für die Origin-Verbindung* ist die Anzahl der Sekunden, die beim Versuch, eine Verbindung zum CloudFront Ursprung herzustellen, gewartet wird.
Die Anzahl der *Versuche, eine Verbindung zum Ursprung herzustellen*, gibt an, wie oft CloudFront versucht wird, eine Verbindung zum Ursprung herzustellen.
Zusammen bestimmen diese Einstellungen, wie lange CloudFront versucht wird, eine Verbindung zum Ursprung herzustellen, bevor ein Failover zum sekundären Ursprung erfolgt (im Fall einer Ursprungsgruppe) oder eine Fehlermeldung an den Viewer zurückgegeben wird. CloudFront Wartet standardmäßig bis zu 30 Sekunden (3 Versuche à 10 Sekunden), bevor versucht wird, eine Verbindung zum sekundären Ursprung herzustellen, oder eine Fehlermeldung zurückgegeben wird. Sie können diese Zeit reduzieren, indem Sie ein kürzeres Verbindungs-Timeout, weniger Versuche oder beides angeben.
Weitere Informationen finden Sie unter [Steuern von Timeouts und Verbindungsversuchen für Ursprünge](high_availability_origin_failover.md#controlling-attempts-and-timeouts).
### Ursprungs-Reaktions-Timeout
Das *Ursprungs-Reaktions-Timeout*, das auch als *Ursprungs-Lese-Timeout* oder *Ursprungs-Anforderungs-Timeout* bezeichnet wird, gilt für Folgendes:
+ Die Zeitspanne in Sekunden, die auf eine Antwort CloudFront wartet, nachdem eine Anfrage an den Ursprung weitergeleitet wurde.
+ Die Zeitspanne in Sekunden, die nach dem Empfang eines Antwortpakets vom Ursprung und vor dem Empfang des nächsten Pakets CloudFront gewartet wird.
CloudFront Das Verhalten hängt von der HTTP-Methode der Viewer-Anfrage ab:
+ `GET`und `HEAD` Anfragen — Wenn der Ursprung nicht innerhalb von 30 Sekunden reagiert oder 30 Sekunden lang nicht mehr reagiert, wird CloudFront die Verbindung unterbrochen. Wenn die angegebene Anzahl der ursprünglichen [Verbindungsversuche](DownloadDistValuesOrigin.md#origin-connection-attempts) mehr als 1 beträgt, wird erneut CloudFront versucht, eine vollständige Antwort zu erhalten. CloudFront versucht bis zu 3 Mal, je nach dem Wert der Einstellung *für ursprüngliche Verbindungsversuche*. Wenn der Ursprung beim letzten Versuch keine Antwort sendet, unternimmt CloudFront erst dann einen weiteren Versuch, wenn die nächste Anfrage für Inhalte auf demselben Ursprung empfangen wird.
+ `DELETE`,`OPTIONS`, `PATCH``PUT`, und `POST` Anfragen — Wenn der Absender nicht innerhalb von 30 Sekunden antwortet, wird die CloudFront Verbindung unterbrochen und es wird nicht erneut versucht, den Ursprung zu kontaktieren. Der Client kann die Anfrage erneut senden, falls erforderlich.
Sie können das Reaktions-Timeout für einen Amazon S3-Ursprung (ein S3-Bucket, der *nicht* mit statischem Website-Hosting konfiguriert ist) nicht ändern.
### Gleichzeitige Anfragen für dasselbe Objekt (Zusammenfassung von Anfragen)
Wenn ein CloudFront Edge-Standort eine Anfrage für ein Objekt erhält und sich das Objekt nicht im Cache befindet oder das zwischengespeicherte Objekt abgelaufen ist, wird die Anfrage CloudFront sofort an den Ursprung gesendet. Wenn es jedoch gleichzeitige Anfragen für dasselbe Objekt gibt, d. h. wenn zusätzliche Anfragen für dasselbe Objekt (mit demselben Cache-Schlüssel) am Edge-Standort ankommen, bevor die Antwort auf die erste Anfrage CloudFront empfangen wird, wird eine CloudFront Pause eingelegt, bevor die zusätzlichen Anfragen an den Ursprung weitergeleitet werden. Diese kurze Pause trägt dazu bei, die Belastung des Ursprungs zu reduzieren. CloudFront sendet die Antwort der ursprünglichen Anfrage auf alle Anfragen, die während der Pause eingegangen sind. Dies wird als *Request Collapsing* (Zusammenfassung von Anfragen) bezeichnet. In den CloudFront Protokollen wird die erste Anfrage `Miss` im `x-edge-result-type` Feld als eine identifiziert, und die ausgeblendeten Anfragen werden als a gekennzeichnet. `Hit` Weitere Hinweise zu CloudFront Protokollen finden Sie unter[CloudFront und Edge-Funktionsprotokollierung](logging.md).
CloudFront reduziert nur Anfragen, die sich einen [*Cache-Schlüssel*](understanding-the-cache-key.md) teilen. Wenn die zusätzlichen Anfragen nicht denselben Cache-Schlüssel verwenden, weil Sie beispielsweise so konfiguriert haben, dass der Cache CloudFront auf der Grundlage von Anforderungsheadern, Cookies oder Abfragezeichenfolgen gespeichert wird, werden alle Anfragen mit einem eindeutigen Cache-Schlüssel an Ihren Ursprung CloudFront weitergeleitet.
Um die Reduzierung von Anforderungen insgesamt zu verhindern, können Sie die verwaltete Cache-Richtlinie `CachingDisabled` verwenden, die auch das Caching verhindert. Weitere Informationen finden Sie unter [Verwenden verwalteter Cache-Richtlinien](using-managed-cache-policies.md).
Wenn Sie eine Reduzierung von Anforderungen für bestimmte Objekte verhindern möchten, können Sie die minimale TTL für das Cacheverhalten auf 0 setzen *und* den Ursprung so konfigurieren, dass `Cache-Control: private`, `Cache-Control: no-store`, `Cache-Control: no-cache`, `Cache-Control: max-age=0` oder `Cache-Control: s-maxage=0` gesendet wird. Diese Konfigurationen erhöhen die Belastung Ihres Ursprungs und führen zu zusätzlicher Latenz für gleichzeitige Anfragen, die angehalten werden, während auf die Antwort auf die CloudFront erste Anfrage gewartet wird.
**Wichtig**
Unterstützt derzeit CloudFront nicht das Zusammenklappen von Anfragen, wenn Sie die Cookie-Weiterleitung in der [Cache-Richtlinie, der ursprünglichen [Anforderungsrichtlinie](controlling-origin-requests.md)](controlling-the-cache-key.md) oder den älteren Cache-Einstellungen aktivieren.
## So CloudFront werden Antworten von Ihrem Amazon S3 S3-Absender verarbeitet
Erfahren Sie, wie Antworten von Ihrem Amazon S3 S3-Absender CloudFront verarbeitet werden.
**Contents**
+ [Abgebrochene Anfragen](#response-s3-canceled-requests)
+ [HTTP-Antwort-Header, die CloudFront entfernt oder aktualisiert werden](#response-s3-removed-headers)
+ [Maximale Dateigröße, die zwischengespeichert werden kann](#ResponseS3MaxFileSize)
+ [Umleitungen](#ResponseS3Redirects)
### Abgebrochene Anfragen
Wenn sich ein Objekt nicht im Edge-Cache befindet und ein Betrachter eine Sitzung beendet (z. B. einen Browser schließt), nachdem CloudFront er das Objekt von Ihrem Ursprung abgerufen hat, aber bevor es das angeforderte Objekt liefern kann, wird das Objekt CloudFront nicht am Edge-Standort zwischengespeichert.
### HTTP-Antwort-Header, die CloudFront entfernt oder aktualisiert werden
CloudFront entfernt oder aktualisiert die folgenden Header-Felder, bevor die Antwort von Ihrem Amazon S3 S3-Ursprung an den Viewer weitergeleitet wird:
+ `X-Amz-Id-2`
+ `X-Amz-Request-Id`
+ `Set-Cookie`— Wenn Sie CloudFront die Weiterleitung von Cookies konfigurieren, wird das `Set-Cookie` Header-Feld an Clients weitergeleitet. Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Cookies](Cookies.md).
+ `Trailer`
+ `Transfer-Encoding`— Wenn Ihr Amazon S3 S3-Ursprung dieses Header-Feld zurückgibt, CloudFront setzt er den Wert auf, `chunked` bevor die Antwort an den Betrachter zurückgesendet wird.
+ `Upgrade`
+ `Via`— CloudFront setzt den Wert in der Antwort an den Zuschauer auf den folgenden Wert:
`Via: `*http-version* *alphanumeric-string*`.cloudfront.net (CloudFront)`
Der Wert ist beispielsweise wie folgt:
`Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)`
### Maximale Dateigröße, die zwischengespeichert werden kann
Die maximale Größe eines Antworttextes, der in seinem Cache CloudFront gespeichert wird, beträgt 50 GB. Dazu gehören auch Antworten für aufgeteilte Übertragungen, in denen kein Wert für die `Content-Length`-Kopfzeile angegeben wurde.
Sie können ein Objekt zwischenspeichern, das größer als diese Größe ist, indem Sie Bereichsanforderungen verwenden, um die Objekte in Teilen anzufordern, die jeweils 50 GB oder weniger groß sind. CloudFront CloudFrontspeichert diese Teile im Cache, da jeder von ihnen 50 GB oder weniger groß ist. Nachdem der Viewer alle Teile des Objekts abgerufen hat, kann er das ursprüngliche, größere Objekt rekonstruieren. Weitere Informationen finden Sie unter [Verwenden von Bereichsanforderungen zum Zwischenspeichern großer Objekte](RangeGETs.md#cache-large-objects-with-range-requests).
### Umleitungen
Sie können einen Amazon S3-Bucket so konfigurieren, dass alle Anfragen an einen anderen Host-Namen umgeleitet werden. Dabei kann es sich um einen anderen Amazon S3-Bucket oder um einen HTTP-Server handeln. Wenn Sie einen Bucket so konfigurieren, dass er alle Anfragen umleitet, und wenn der Bucket der Ursprung für eine CloudFront Distribution ist, empfehlen wir, den Bucket so zu konfigurieren, dass er alle Anfragen an eine CloudFront Distribution umleitet, indem Sie entweder den Domainnamen für die Distribution (z. B. d111111abcdef8.cloudfront.net) oder einen alternativen Domainnamen (einen CNAME) verwenden, der einer Distribution zugeordnet ist (z. B. example.com). Andernfalls werden Viewer-Anfragen umgangen CloudFront und die Objekte werden direkt vom neuen Ursprung aus bedient.
**Anmerkung**
Wenn Sie Viewer-Anforderungen an einen alternativen Domain-Namen umleiten, müssen Sie auch den DNS-Service für Ihre Domain aktualisieren, indem Sie einen CNAME-Datensatz hinzufügen. Weitere Informationen finden Sie unter [Verwenden Sie Benutzerdefiniert, URLs indem Sie alternative Domainnamen hinzufügen (CNAMEs)](CNAMEs.md).
Wenn Sie einen Bucket so konfigurieren, dass er alle Anfragen umleitet, geschieht Folgendes:
1. Ein Betrachter (z. B. ein Browser) fordert ein Objekt von an CloudFront.
1. CloudFront leitet die Anfrage an den Amazon S3 S3-Bucket weiter, der der Ursprung Ihrer Distribution ist.
1. Amazon S3 gibt einen HTTP-Statuscode 301 (dauerhaft verschoben) sowie den neuen Speicherort zurück.
1. CloudFront speichert den Umleitungsstatuscode und den neuen Standort im Cache und gibt die Werte an den Betrachter zurück. CloudFront folgt nicht der Weiterleitung, um das Objekt vom neuen Standort abzurufen.
1. Der Betrachter sendet eine weitere Anfrage für das Objekt, aber diesmal gibt der Betrachter den neuen Speicherort an, von dem es abgerufen wurde CloudFront:
+ Wenn der Amazon S3 S3-Bucket alle Anfragen an eine CloudFront Distribution umleitet und entweder den Domainnamen für die Distribution oder einen alternativen Domainnamen verwendet, CloudFront fordert er das Objekt vom Amazon S3 S3-Bucket oder vom HTTP-Server am neuen Standort an. Wenn der neue Speicherort das Objekt zurückgibt, wird es an den Viewer CloudFront zurückgegeben und an einem Edge-Speicherort zwischengespeichert.
+ Wenn der Amazon S3 S3-Bucket Anfragen an einen anderen Standort umleitet, wird die zweite Anfrage umgangen. CloudFront Der Amazon S3 S3-Bucket oder der HTTP-Server am neuen Standort gibt das Objekt direkt an den Viewer zurück, sodass das Objekt niemals in einem CloudFront Edge-Cache zwischengespeichert wird.
# Verhalten von Anfragen und Antworten für benutzerdefinierte Ursprungsserver
In den folgenden Abschnitten erfahren Sie, wie Anfragen und Antworten CloudFront verarbeitet werden, wenn Sie benutzerdefinierte Ursprünge verwenden:
**Topics**
+ [Wie CloudFront verarbeitet und leitet Anfragen an Ihren benutzerdefinierten Absender weiter](#RequestBehaviorCustomOrigin)
+ [Wie CloudFront werden Antworten von Ihrem benutzerdefinierten Ursprung verarbeitet](#ResponseBehaviorCustomOrigin)
## Wie CloudFront verarbeitet und leitet Anfragen an Ihren benutzerdefinierten Absender weiter
Erfahren Sie, wie Zuschaueranfragen CloudFront verarbeitet und die Anfragen an Ihren benutzerdefinierten Ursprung weiterleitet.
**Contents**
+ [Authentifizierung](#RequestCustomClientAuth)
+ [Cache-Dauer und Mindest-TTL](#RequestCustomCaching)
+ [Client-IP-Adressen](#RequestCustomIPAddresses)
+ [Clientseitige SSL-Authentifizierung](#RequestCustomClientSideSslAuth)
+ [Komprimierung](#RequestCustomCompression)
+ [Bedingte Anforderungen](#RequestCustomConditionalGETs)
+ [Cookies](#RequestCustomCookies)
+ [Cross-Origin Resource Sharing (CORS)](#request-custom-cors)
+ [Verschlüsselung](#RequestCustomEncryption)
+ [GET-Anfragen mit Anfragetext](#RequestCustom-get-body)
+ [HTTP-Methoden](#RequestCustomHTTPMethods)
+ [Header und CloudFront Verhalten von HTTP-Anfragen (benutzerdefiniert und Amazon S3 S3-Ursprünge)](#request-custom-headers-behavior)
+ [HTTP-Version](#RequestCustomHTTPVersion)
+ [Maximale Länge einer Anfrage und maximale Länge einer URL](#RequestCustomMaxRequestStringLength)
+ [OCSP-Stapling](#request-custom-ocsp-stapling)
+ [Persistente Verbindungen](#request-custom-persistent-connections)
+ [Protokolle](#RequestCustomProtocols)
+ [Abfragezeichenfolgen](#RequestCustomQueryStrings)
+ [Timeout der Ursprungsverbindung und Verbindungsversuche zum Ursprung](#custom-origin-timeout-attempts)
+ [Ursprungs-Reaktions-Timeout](#request-custom-request-timeout)
+ [Gleichzeitige Anfragen für dasselbe Objekt (Zusammenfassung von Anfragen)](#request-custom-traffic-spikes)
+ [`User-Agent`-Header](#request-custom-user-agent-header)
### Authentifizierung
Wenn Sie den `Authorization`-Header an Ihren Ursprung weiterleiten, können Sie Ihren Ursprungsserver so konfigurieren, dass eine Client-Authentifizierung für die folgenden Arten von Anforderungen angefordert wird:
+ `DELETE`
+ `GET`
+ `HEAD`
+ `PATCH`
+ `PUT`
+ `POST`
Für `OPTIONS` Anfragen kann die Client-Authentifizierung *nur* konfiguriert werden, wenn Sie die folgenden CloudFront Einstellungen verwenden:
+ CloudFront ist so konfiguriert, dass der `Authorization` Header an Ihren Ursprung weitergeleitet wird
+ CloudFront ist so konfiguriert, dass die Antwort auf `OPTIONS` Anfragen *nicht* zwischengespeichert wird
Weitere Informationen finden Sie unter [Konfigurieren von CloudFront zur Weiterleitung des `Authorization`-Headers](add-origin-custom-headers.md#add-origin-custom-headers-forward-authorization).
Sie können HTTP oder HTTPS verwenden, um Anforderungen an Ihren Ursprungsserver weiterzuleiten. Weitere Informationen finden Sie unter [Verwenden Sie HTTPS mit CloudFront](using-https.md).
### Cache-Dauer und Mindest-TTL
Um zu kontrollieren, wie lange Ihre Objekte in einem CloudFront Cache bleiben, bevor CloudFront sie eine weitere Anfrage an Ihren Ursprung weiterleiten, können Sie:
+ Ihren Ursprungsserver so konfigurieren, dass jedem Objekt ein `Cache-Control`- oder `Expires`-Header-Feld hinzugefügt wird
+ Geben Sie einen Wert für Minimale TTL in CloudFront Cache-Verhalten an.
+ Den Standardwert von 24 Stunden verwenden
Weitere Informationen finden Sie unter [Verwalten der Dauer, die Inhalte im Cache bleiben (Ablauf)](Expiration.md).
### Client-IP-Adressen
Wenn ein Viewer eine Anfrage an sendet CloudFront und keinen Anforderungsheader enthält, CloudFront ruft er die IP-Adresse des Viewers aus der TCP-Verbindung ab, fügt einen `X-Forwarded-For` Header hinzu, der die IP-Adresse enthält, und leitet die Anfrage an den Ursprung weiter. `X-Forwarded-For` Wenn CloudFront z. B. die IP-Adresse `192.0.2.2` von der TCP-Verbindung abruft, wird der folgende Header an den Ursprungs-Server weitergeleitet:
`X-Forwarded-For: 192.0.2.2`
Wenn ein Betrachter eine Anfrage an den Anforderungsheader sendet CloudFront und diesen einschließt, CloudFront ruft er die IP-Adresse des Viewers aus der TCP-Verbindung ab, hängt sie an das Ende des `X-Forwarded-For` Headers an und leitet die Anfrage an den Ursprung weiter. `X-Forwarded-For` Wenn die Viewer-Anfrage beispielsweise die IP-Adresse der TCP-Verbindung enthält `X-Forwarded-For: 192.0.2.4,192.0.2.3` und diese CloudFront `192.0.2.2` abruft, leitet sie den folgenden Header an den Ursprung weiter:
`X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2`
Einige Anwendungen, wie Load Balancer (einschließlich Elastic Load Balancing), Webanwendungs-Firewalls, Reverse-Proxys, Intrusion Prevention-Systeme und API Gateway, fügen die IP-Adresse des CloudFront Edge-Servers, der die Anfrage weitergeleitet hat, an das Ende des Headers an. `X-Forwarded-For` Wenn beispielsweise `X-Forwarded-For: 192.0.2.2` in einer Anfrage CloudFront enthalten ist, dass sie an ELB weitergeleitet wird, und wenn die IP-Adresse des CloudFront Edge-Servers 192.0.2.199 lautet, enthält die Anfrage, die Ihre Instance empfängt, den folgenden Header: EC2
`X-Forwarded-For: 192.0.2.2,192.0.2.199`
**Anmerkung**
Der `X-Forwarded-For` Header enthält IPv4 Adressen (wie 192.0.2.44) und IPv6 Adressen (wie 2001:0 db 8:85 a3: :8a2e: 0370:7334).
Beachten Sie auch, dass der `X-Forwarded-For` Header von jedem Knoten auf dem Pfad zum aktuellen Server geändert werden kann (). CloudFront Weitere Informationen finden Sie im Abschnitt 8.1 unter [RFC 7239](https://datatracker.ietf.org/doc/html/rfc7239). Sie können den Header auch mithilfe von CloudFront Edge-Compute-Funktionen ändern.
### Clientseitige SSL-Authentifizierung
CloudFront unterstützt die gegenseitige TLS-Authentifizierung (mTLS), bei der sich sowohl der Client als auch der Server gegenseitig mithilfe von Zertifikaten authentifizieren. Wenn mTLS konfiguriert ist, CloudFront kann es Client-Zertifikate während des TLS-Handshakes validieren und optional CloudFront Funktionen ausführen, um eine benutzerdefinierte Validierungslogik zu implementieren.
Bei Quellen, die clientseitige Zertifikate anfordern, obwohl mTLS nicht konfiguriert ist, wird die Anfrage gelöscht. CloudFront
Weitere Informationen zur Konfiguration von mTLS finden Sie unter. [Ordnen Sie eine CloudFront Verbindungsfunktion zu](connection-functions.md)
CloudFront unterstützt keine Client-Authentifizierung mit clientseitigen SSL-Zertifikaten. Wenn ein Ursprung ein clientseitiges Zertifikat anfordert, CloudFront wird die Anfrage gelöscht.
### Komprimierung
Weitere Informationen finden Sie unter [Bereitstellen von komprimierten Dateien](ServingCompressedFiles.md).
### Bedingte Anforderungen
Wenn CloudFront er eine Anforderung für ein Objekt erhält, das aus einem Edge-Cache abgelaufen ist, leitet er die Anfrage an den Ursprung weiter, um entweder die neueste Version des Objekts abzurufen oder um vom Ursprung eine Bestätigung zu erhalten, dass der CloudFront Edge-Cache bereits über die neueste Version verfügt. In der Regel hat der Ursprung, an den das Objekt zuletzt gesendet wurde CloudFront, einen `ETag` Wert, einen `LastModified` Wert oder beide Werte in die Antwort aufgenommen. Fügt in der neuen Anfrage, die an den Ursprung CloudFront weiterleitet, eine oder beide der folgenden Angaben CloudFront hinzu:
+ Einen `If-Match`- oder `If-None-Match`-Header mit dem `ETag`-Wert für die abgelaufene Version des Objekts
+ Einen `If-Modified-Since`-Header mit dem `LastModified`-Wert für die abgelaufene Version des Objekts
Der Ursprung verwendet diese Informationen, um zu ermitteln, ob das Objekt aktualisiert wurde und ob daher das gesamte Objekt CloudFront oder nur ein HTTP 304-Statuscode (nicht geändert) zurückgegeben werden soll.
**Anmerkung**
`If-Modified-Since`und `If-None-Match` bedingte Anfragen werden nicht unterstützt, wenn die Konfiguration so konfiguriert CloudFront ist, dass Cookies (alle oder ein Teil davon) weitergeleitet werden.
Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Cookies](Cookies.md).
### Cookies
Sie können so konfigurieren CloudFront , dass Cookies an Ihren Ursprung weitergeleitet werden. Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Cookies](Cookies.md).
### Cross-Origin Resource Sharing (CORS)
Wenn Sie die Einstellungen CloudFront für die gemeinsame Nutzung von Ressourcen zwischen verschiedenen Quellen beibehalten möchten, konfigurieren Sie die Konfiguration so, CloudFront dass der `Origin` Header an Ihren Ursprung weitergeleitet wird. Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Anforderungsheadern](header-caching.md).
### Verschlüsselung
Sie können verlangen, dass Zuschauer HTTPS verwenden, um Anfragen an Ihren benutzerdefinierten Ursprung zu senden CloudFront, CloudFront und Anfragen an Ihren benutzerdefinierten Ursprung weiterleiten müssen, indem Sie das Protokoll verwenden, das vom Betrachter verwendet wird. Weitere Informationen finden Sie in den folgenden Verteilungseinstellungen:
+ [Viewer-Protokollrichtlinien](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy)
+ [Protokoll (nur benutzerdefinierte Ursprünge)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy)
CloudFront leitet HTTPS-Anfragen mithilfe der Protokolle SSLv3, TLSv1 .0, TLSv1 .1, TLSv1 .2 und TLSv1 .3 an den Ursprungsserver weiter. Für benutzerdefinierte Ursprünge können Sie die SSL-Protokolle auswählen, die Sie für die Kommunikation mit Ihrem Ursprung verwenden CloudFront möchten:
+ Wenn du die CloudFront Konsole verwendest, wähle Protokolle mithilfe der Kontrollkästchen **Origin SSL Protocols** aus. Weitere Informationen finden Sie unter [Eine Distribution erstellen](distribution-web-creating-console.md).
+ Wenn Sie die CloudFront API verwenden, geben Sie Protokolle mithilfe des `OriginSslProtocols` Elements an. Weitere Informationen finden Sie unter [OriginSslProtocols](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginSslProtocols.html)und [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html)in der *Amazon CloudFront API-Referenz*.
Wenn der Ursprung ein Amazon S3 S3-Bucket ist, CloudFront wird standardmäßig TLSv1 .3 verwendet.
**Wichtig**
Andere Versionen von SSL und TLS werden nicht unterstützt.
Weitere Informationen zur Verwendung von HTTPS mit CloudFront finden Sie unter[Verwenden Sie HTTPS mit CloudFront](using-https.md). Eine Liste der Chiffren, die die HTTPS-Kommunikation zwischen Zuschauern und und zwischen CloudFront und Ihrem Absender CloudFront unterstützen CloudFront, finden Sie unter. [Unterstützte Protokolle und Chiffren zwischen Zuschauern und CloudFront](secure-connections-supported-viewer-protocols-ciphers.md)
### GET-Anfragen mit Anfragetext
Wenn eine `GET` Viewer-Anfrage einen Hauptteil enthält, wird der HTTP-Statuscode 403 (Forbidden) an den Betrachter CloudFront zurückgegeben.
### HTTP-Methoden
Wenn Sie so konfigurieren CloudFront , dass alle HTTP-Methoden verarbeitet werden, die es unterstützt, CloudFront akzeptiert es die folgenden Anfragen von Zuschauern und leitet sie an Ihren benutzerdefinierten Ursprung weiter:
+ `DELETE`
+ `GET`
+ `HEAD`
+ `OPTIONS`
+ `PATCH`
+ `POST`
+ `PUT`
CloudFront speichert immer Antworten auf `GET` und `HEAD` Anfragen im Cache. Sie können auch so konfigurieren CloudFront , dass Antworten auf `OPTIONS` Anfragen zwischengespeichert werden. CloudFront speichert Antworten auf Anfragen, die die anderen Methoden verwenden, nicht im Cache.
Informationen zur Konfiguration Ihres benutzerdefinierten Ursprungsservers für die Verarbeitung dieser Methoden finden Sie in der Dokumentation zu Ihrem Ursprungsserver.
**Wichtig**
Wenn Sie so konfigurieren CloudFront , dass alle CloudFront unterstützten HTTP-Methoden akzeptiert und an Ihren Ursprung weitergeleitet werden, konfigurieren Sie Ihren Ursprungsserver so, dass er alle Methoden verarbeitet. Wenn Sie beispielsweise so konfigurieren CloudFront , dass diese Methoden akzeptiert und weitergeleitet werden, weil Sie sie verwenden möchten`POST`, müssen Sie Ihren Ursprungsserver so konfigurieren, dass er `DELETE` Anfragen entsprechend verarbeitet, sodass Zuschauer keine Ressourcen löschen können, die Sie nicht möchten. Weitere Informationen finden Sie in der Dokumentation zu Ihrem HTTP-Server.
### Header und CloudFront Verhalten von HTTP-Anfragen (benutzerdefiniert und Amazon S3 S3-Ursprünge)
In der folgenden Tabelle sind HTTP-Anfrage-Header aufgelistet, die Sie sowohl an benutzerdefinierte als auch Amazon S3-Ursprünge weiterleiten können (mit Ausnahmen, auf die hingewiesen wird). Für jeden Header umfasst die Tabelle Informationen über Folgendes:
+ CloudFront Verhalten, wenn Sie nicht so konfigurieren CloudFront , dass der Header an Ihren Ursprung weitergeleitet wird, was dazu führt CloudFront , dass Ihre Objekte auf der Grundlage von Header-Werten zwischengespeichert werden.
+ Ob Sie so konfigurieren können CloudFront , dass Objekte auf der Grundlage von Header-Werten für diesen Header zwischengespeichert werden.
Sie können so konfigurieren CloudFront , dass Objekte auf der Grundlage von Werten in den `User-Agent` Kopfzeilen `Date` und zwischengespeichert werden, wir empfehlen dies jedoch nicht. Diese Header haben viele mögliche Werte, und das Zwischenspeichern auf der Grundlage ihrer Werte würde dazu führen, dass deutlich mehr Anfragen CloudFront an Ihren Ursprung weitergeleitet werden.
Weitere Informationen zum Zwischenspeichern auf Basis von Header-Werten finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Anforderungsheadern](header-caching.md).
| Header | Verhalten, wenn Sie nicht so konfigurieren, dass es auf der Grundlage von CloudFront Header-Werten zwischengespeichert wird | Das Zwischenspeichern auf Basis von Header-Werten wird unterstützt |
| --- | --- | --- |
| Anderweitig definierte Header | **Legacy-Cache-Einstellungen** — CloudFront leitet die Header an Ihren Ursprung weiter. | Ja |
| `Accept` | CloudFront entfernt den Header. | Ja |
| `Accept-Charset` | CloudFront entfernt den Header. | Ja |
| `Accept-Encoding` | Wenn der Wert `gzip` oder enthält`br`, CloudFront leitet er einen normalisierten `Accept-Encoding` Header an Ihren Ursprung weiter. Weitere Informationen erhalten Sie unter [Komprimierungsunterstützung](cache-key-understand-cache-policy.md#cache-policy-compressed-objects) und [Bereitstellen von komprimierten Dateien](ServingCompressedFiles.md). | Ja |
| `Accept-Language` | CloudFront entfernt den Header. | Ja |
| `Authorization` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html) | Ja |
| `Cache-Control` | CloudFront leitet den Header an Ihren Ursprung weiter. | Nein |
| `CloudFront-Forwarded-Proto` | CloudFront fügt den Header nicht hinzu, bevor die Anfrage an Ihren Ursprung weitergeleitet wurde. Weitere Informationen finden Sie unter [Konfigurieren der Zwischenspeicherung basierend auf dem Protokoll der Anforderung](header-caching.md#header-caching-web-protocol). | Ja |
| `CloudFront-Is-Desktop-Viewer` | CloudFront fügt den Header nicht hinzu, bevor die Anfrage an Ihren Absender weitergeleitet wird. Weitere Informationen finden Sie unter [Konfigurieren der Zwischenspeicherung basierend auf dem Gerätetyp](header-caching.md#header-caching-web-device). | Ja |
| `CloudFront-Is-Mobile-Viewer` | CloudFront fügt den Header nicht hinzu, bevor die Anfrage an Ihren Absender weitergeleitet wird. Weitere Informationen finden Sie unter [Konfigurieren der Zwischenspeicherung basierend auf dem Gerätetyp](header-caching.md#header-caching-web-device). | Ja |
| `CloudFront-Is-Tablet-Viewer` | CloudFront fügt den Header nicht hinzu, bevor die Anfrage an Ihren Absender weitergeleitet wird. Weitere Informationen finden Sie unter [Konfigurieren der Zwischenspeicherung basierend auf dem Gerätetyp](header-caching.md#header-caching-web-device). | Ja |
| `CloudFront-Viewer-Country` | CloudFront fügt den Header nicht hinzu, bevor die Anfrage an Ihren Absender weitergeleitet wird. | Ja |
| `Connection` | CloudFront ersetzt diesen Header durch, `Connection: Keep-Alive` bevor die Anfrage an Ihren Absender weitergeleitet wird. | Nein |
| `Content-Length` | CloudFront leitet den Header an Ihren Ursprung weiter. | Nein |
| `Content-MD5` | CloudFront leitet den Header an Ihren Ursprung weiter. | Ja |
| `Content-Type` | CloudFront leitet den Header an Ihren Ursprung weiter. | Ja |
| `Cookie` | Wenn Sie CloudFront die Weiterleitung von Cookies konfigurieren, wird das `Cookie` Header-Feld an Ihren Ursprung weitergeleitet. Wenn Sie dies nicht tun, CloudFront wird das `Cookie` Header-Feld entfernt. Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Cookies](Cookies.md). | Nein |
| `Date` | CloudFront leitet den Header an Ihren Ursprung weiter. | Ja, wird aber nicht empfohlen |
| `Expect` | CloudFront entfernt den Header. | Ja |
| `From` | CloudFront leitet den Header an Ihren Ursprung weiter. | Ja |
| `Host` | CloudFront setzt den Wert auf den Domainnamen des Ursprungs, der dem angeforderten Objekt zugeordnet ist. Sie können nicht auf der Grundlage des Host-Headers für Amazon S3 oder MediaStore Origins zwischenspeichern. | Ja (benutzerdefiniert) Nein (S3 und MediaStore) |
| `If-Match` | CloudFront leitet den Header an Ihren Ursprung weiter. | Ja |
| `If-Modified-Since` | CloudFront leitet den Header an Ihren Ursprung weiter. | Ja |
| `If-None-Match` | CloudFront leitet den Header an Ihren Ursprung weiter. | Ja |
| `If-Range` | CloudFront leitet den Header an Ihren Ursprung weiter. | Ja |
| `If-Unmodified-Since` | CloudFront leitet den Header an Ihren Ursprung weiter. | Ja |
| `Max-Forwards` | CloudFront leitet den Header an Ihren Ursprung weiter. | Nein |
| `Origin` | CloudFront leitet den Header an Ihren Ursprung weiter. | Ja |
| `Pragma` | CloudFront leitet den Header an Ihren Ursprung weiter. | Nein |
| `Proxy-Authenticate` | CloudFront entfernt den Header. | Nein |
| `Proxy-Authorization` | CloudFront entfernt den Header. | Nein |
| `Proxy-Connection` | CloudFront entfernt den Header. | Nein |
| `Range` | CloudFront leitet den Header an Ihren Ursprung weiter. Weitere Informationen finden Sie unter [Wie CloudFront werden Teilanfragen für ein Objekt (BereichGETs) verarbeitet](RangeGETs.md). | Ja, standardmäßig |
| `Referer` | CloudFront entfernt den Header. | Ja |
| `Request-Range` | CloudFront leitet den Header an Ihren Ursprung weiter. | Nein |
| `TE` | CloudFront entfernt den Header. | Nein |
| `Trailer` | CloudFront entfernt den Header. | Nein |
| `Transfer-Encoding` | CloudFront leitet den Header an Ihren Ursprung weiter. | Nein |
| `Upgrade` | CloudFront entfernt den Header, sofern Sie keine WebSocket Verbindung hergestellt haben. | Nein (außer für WebSocket Verbindungen) |
| `User-Agent` | CloudFront ersetzt den Wert dieses Header-Felds durch`Amazon CloudFront`. Wenn Sie Ihre Inhalte je CloudFront nach dem Gerät, das der Benutzer verwendet, zwischenspeichern möchten, finden Sie weitere Informationen unter[Konfigurieren der Zwischenspeicherung basierend auf dem Gerätetyp](header-caching.md#header-caching-web-device). | Ja, wird aber nicht empfohlen |
| `Via` | CloudFront leitet den Header an Ihren Ursprung weiter. | Ja |
| `Warning` | CloudFront leitet den Header an Ihren Ursprung weiter. | Ja |
| `X-Amz-Cf-Id` | CloudFront fügt den Header zur Viewer-Anfrage hinzu, bevor die Anfrage an Ihren Ursprung weitergeleitet wird. Der Header-Wert enthält eine verschlüsselte Zeichenfolge, die die Anfrage eindeutig bezeichnet. | Nein |
| `X-Edge-*` | CloudFront entfernt alle `X-Edge-*` Header. | Nein |
| `X-Forwarded-For` | CloudFront leitet den Header an Ihren Ursprung weiter. Weitere Informationen finden Sie unter [Client-IP-Adressen](#RequestCustomIPAddresses). | Ja |
| `X-Forwarded-Proto` | CloudFront entfernt den Header. | Nein |
| `X-HTTP-Method-Override` | CloudFront entfernt den Header. | Ja |
| `X-Real-IP` | CloudFront entfernt den Header. | Nein |
### HTTP-Version
CloudFront leitet Anfragen über HTTP/1.1 an Ihren benutzerdefinierten Ursprung weiter.
### Maximale Länge einer Anfrage und maximale Länge einer URL
Die maximale Länge einer Anfrage – einschließlich des Pfads, der Abfragezeichenfolge (falls vorhanden) und der Header – beträgt 20 480 Byte.
CloudFront konstruiert aus der Anfrage eine URL. Die maximale Länge dieser URL beträgt 8 192 Byte.
Wenn eine Anfrage oder eine URL diese Höchstwerte überschreitet, CloudFront gibt es den HTTP-Statuscode 413, Request Entity Too Large, an den Viewer zurück und beendet dann die TCP-Verbindung zum Viewer.
### OCSP-Stapling
Wenn ein Betrachter eine HTTPS-Anfrage für ein Objekt sendet, muss einer CloudFront oder der Betrachter bei der Zertifizierungsstelle (CA) bestätigen, dass das SSL-Zertifikat für die Domain nicht gesperrt wurde. OCSP-Hefting beschleunigt die Zertifikatsvalidierung CloudFront , da das Zertifikat validiert und die Antwort von der CA zwischengespeichert werden kann, sodass der Client das Zertifikat nicht direkt bei der CA validieren muss.
Die Leistungssteigerung durch OCSP-Stapling ist deutlicher spürbar, wenn CloudFront viele HTTPS-Anfragen für Objekte in derselben Domain erhält. Jeder Server an einem CloudFront Edge-Standort muss eine separate Überprüfungsanforderung einreichen. Wenn CloudFront viele HTTPS-Anfragen für dieselbe Domain erhält, hat jeder Server an dem Edge-Standort nach kurzer Zeit hat eine Antwort von der CA vorliegen, die er an ein Paket im SSL-Handshake „heften” (engl. „to staple”) kann; wenn der Betrachter von der Gültigkeit des Zertifikats überzeugt ist, kann CloudFront das angeforderte Objekt übertragen. Wenn Ihre Distribution an einem CloudFront Edge-Standort nicht viel Verkehr erhält, ist es wahrscheinlicher, dass neue Anfragen an einen Server weitergeleitet werden, der das Zertifikat noch nicht bei der CA validiert hat. In diesem Fall führt der Viewer den Validierungsschritt separat durch und der CloudFront Server stellt das Objekt bereit. Dieser CloudFront Server sendet auch eine Überprüfungsanfrage an die CA. Wenn er also das nächste Mal eine Anfrage erhält, die denselben Domainnamen enthält, erhält er eine Validierungsantwort von der CA.
### Persistente Verbindungen
Wenn CloudFront Sie eine Antwort von Ihrem Absender erhalten, versucht er, die Verbindung mehrere Sekunden lang aufrechtzuerhalten, falls in diesem Zeitraum eine weitere Anfrage eingeht. Durch eine persistente Verbindung wird die Zeit gespart, die erforderlich ist, um die TCP-Verbindung erneut herzustellen und einen weiteren TLS-Handshake für nachfolgende Anforderungen durchzuführen.
Weitere Informationen, einschließlich solcher zur Konfiguration der Dauer ständiger Verbindungen, finden Sie unter [Keep-Alive-Timeout (nur benutzerdefinierte und VPC-Ursprünge)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginKeepaliveTimeout) im Abschnitt [Referenz für alle Distributionseinstellungen](distribution-web-values-specify.md).
### Protokolle
CloudFront leitet HTTP- oder HTTPS-Anfragen auf folgender Grundlage an den Ursprungsserver weiter:
+ Das Protokoll der Anfrage, an die der Betrachter sendet CloudFront, entweder HTTP oder HTTPS.
+ Der Wert des Felds **Origin Protocol Policy** in der CloudFront Konsole oder, wenn Sie die CloudFront API verwenden, das `OriginProtocolPolicy` Element im `DistributionConfig` komplexen Typ. In der CloudFront Konsole stehen die Optionen „**Nur HTTP“, „Nur** **HTTPS**“ und „**Match Viewer**“ zur Verfügung.
Wenn Sie „**Nur HTTP**“ oder „**Nur HTTPS**“ angeben, CloudFront werden Anfragen mit dem angegebenen Protokoll an den Ursprungsserver weitergeleitet, unabhängig vom Protokoll in der Viewer-Anfrage.
Wenn Sie **Match Viewer** angeben, CloudFront leitet Anfragen mithilfe des Protokolls in der Viewer-Anforderung an den Ursprungsserver weiter. Beachten Sie, dass CloudFront das Objekt nur einmal zwischenspeichert, auch wenn Betrachter ihre Anfragen sowohl über HTTP als auch über HTTPS übertragen.
**Wichtig**
Wenn CloudFront eine Anfrage mithilfe des HTTPS-Protokolls an den Ursprung weitergeleitet wird und der Ursprungsserver ein ungültiges Zertifikat oder ein selbstsigniertes Zertifikat zurückgibt, wird die TCP-Verbindung CloudFront unterbrochen.
Informationen zum Aktualisieren einer Distribution mithilfe der CloudFront Konsole finden Sie unter. [Eine Verteilung aktualisieren](HowToUpdateDistribution.md) Informationen zum Aktualisieren einer Distribution mithilfe der CloudFront API finden Sie [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)in der *Amazon CloudFront API-Referenz*.
### Abfragezeichenfolgen
Sie können konfigurieren, ob CloudFront Abfragezeichenfolgenparameter an Ihren Ursprung weitergeleitet werden. Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Abfragezeichenfolgeparametern](QueryStringParameters.md).
### Timeout der Ursprungsverbindung und Verbindungsversuche zum Ursprung
Das *Timeout für die Origin-Verbindung* ist die Anzahl der Sekunden, die beim Versuch, eine Verbindung zum CloudFront Ursprung herzustellen, gewartet wird.
Die Anzahl der *Versuche, eine Verbindung zum Ursprung herzustellen*, gibt an, wie oft CloudFront versucht wird, eine Verbindung zum Ursprung herzustellen.
Zusammen bestimmen diese Einstellungen, wie lange CloudFront versucht wird, eine Verbindung zum Ursprung herzustellen, bevor ein Failover zum sekundären Ursprung erfolgt (im Fall einer Ursprungsgruppe) oder eine Fehlermeldung an den Viewer zurückgegeben wird. CloudFront Wartet standardmäßig bis zu 30 Sekunden (3 Versuche à 10 Sekunden), bevor versucht wird, eine Verbindung zum sekundären Ursprung herzustellen, oder eine Fehlermeldung zurückgegeben wird. Sie können diese Zeit reduzieren, indem Sie ein kürzeres Verbindungs-Timeout, weniger Versuche oder beides angeben.
Weitere Informationen finden Sie unter [Steuern von Timeouts und Verbindungsversuchen für Ursprünge](high_availability_origin_failover.md#controlling-attempts-and-timeouts).
### Ursprungs-Reaktions-Timeout
Das *Ursprungs-Reaktions-Timeout*, das auch als *Ursprungs-Lese-Timeout* oder *Ursprungs-Anforderungs-Timeout* bezeichnet wird, gilt für Folgendes:
+ Die Zeitspanne in Sekunden, die auf eine Antwort CloudFront wartet, nachdem eine Anfrage an den Ursprung weitergeleitet wurde.
+ Die Zeitspanne in Sekunden, die nach dem Empfang eines Antwortpakets vom Ursprung und vor dem Empfang des nächsten Pakets CloudFront gewartet wird.
CloudFront Das Verhalten hängt von der HTTP-Methode der Viewer-Anfrage ab:
+ `GET`und `HEAD` Anfragen — Wenn der Ursprung nicht oder nicht innerhalb der Dauer des Antwort-Timeouts reagiert, wird die CloudFront Verbindung unterbrochen. Wenn die angegebene Anzahl der ursprünglichen [Verbindungsversuche](DownloadDistValuesOrigin.md#origin-connection-attempts) mehr als 1 beträgt, wird erneut CloudFront versucht, eine vollständige Antwort zu erhalten. CloudFront versucht bis zu 3 Mal, je nach dem Wert der Einstellung *für ursprüngliche Verbindungsversuche*. Wenn der Ursprung beim letzten Versuch keine Antwort sendet, unternimmt CloudFront erst dann einen weiteren Versuch, wenn die nächste Anfrage für Inhalte auf demselben Ursprung empfangen wird.
+ `DELETE`,`OPTIONS`, `PATCH``PUT`, und `POST` Anfragen — Wenn der Absender für die Dauer des Lese-Timeouts nicht reagiert, wird die Verbindung CloudFront unterbrochen und es wird nicht erneut versucht, den Ursprung zu kontaktieren. Der Client kann die Anfrage erneut senden, falls erforderlich.
Weitere Informationen, einschließlich Informationen zum Konfigurieren des Reaktions-Timeouts für den Ursprungs-Server, finden Sie unter [Antwort-Timeout](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).
### Gleichzeitige Anfragen für dasselbe Objekt (Zusammenfassung von Anfragen)
Wenn ein CloudFront Edge-Standort eine Anfrage für ein Objekt empfängt und sich das Objekt nicht im Cache befindet oder das zwischengespeicherte Objekt abgelaufen ist, wird die Anfrage CloudFront sofort an den Ursprung gesendet. Wenn es jedoch gleichzeitige Anfragen für dasselbe Objekt gibt, d. h. wenn zusätzliche Anfragen für dasselbe Objekt (mit demselben Cache-Schlüssel) am Edge-Standort ankommen, bevor die Antwort auf die erste Anfrage CloudFront empfangen wird, wird eine CloudFront Pause eingelegt, bevor die zusätzlichen Anfragen an den Ursprung weitergeleitet werden. Diese kurze Pause trägt dazu bei, die Belastung des Ursprungs zu reduzieren. CloudFront sendet die Antwort der ursprünglichen Anfrage auf alle Anfragen, die während der Pause eingegangen sind. Dies wird als *Request Collapsing* (Zusammenfassung von Anfragen) bezeichnet. In den CloudFront Protokollen wird die erste Anfrage `Miss` im `x-edge-result-type` Feld als eine identifiziert, und die ausgeblendeten Anfragen werden als a gekennzeichnet. `Hit` Weitere Hinweise zu CloudFront Protokollen finden Sie unter[CloudFront und Edge-Funktionsprotokollierung](logging.md).
CloudFront reduziert nur Anfragen, die sich einen [*Cache-Schlüssel*](understanding-the-cache-key.md) teilen. Wenn die zusätzlichen Anfragen nicht denselben Cache-Schlüssel verwenden, weil Sie beispielsweise so konfiguriert haben, dass der Cache CloudFront auf der Grundlage von Anforderungsheadern, Cookies oder Abfragezeichenfolgen gespeichert wird, werden alle Anfragen mit einem eindeutigen Cache-Schlüssel an Ihren Ursprung CloudFront weitergeleitet.
Um die Reduzierung von Anforderungen insgesamt zu verhindern, können Sie die verwaltete Cache-Richtlinie `CachingDisabled` verwenden, die auch das Caching verhindert. Weitere Informationen finden Sie unter [Verwenden verwalteter Cache-Richtlinien](using-managed-cache-policies.md).
Wenn Sie eine Reduzierung von Anforderungen für bestimmte Objekte verhindern möchten, können Sie die minimale TTL für das Cacheverhalten auf 0 setzen *und* den Ursprung so konfigurieren, dass `Cache-Control: private`, `Cache-Control: no-store`, `Cache-Control: no-cache`, `Cache-Control: max-age=0` oder `Cache-Control: s-maxage=0` gesendet wird. Diese Konfigurationen erhöhen die Belastung Ihres Ursprungs und führen zu zusätzlicher Latenz für gleichzeitige Anfragen, die angehalten werden, während auf die Antwort auf die CloudFront erste Anfrage gewartet wird.
**Wichtig**
Unterstützt derzeit CloudFront nicht das Zusammenklappen von Anfragen, wenn Sie die Cookie-Weiterleitung in der [Cache-Richtlinie, der ursprünglichen [Anforderungsrichtlinie](controlling-origin-requests.md)](controlling-the-cache-key.md) oder den älteren Cache-Einstellungen aktivieren.
### `User-Agent`-Header
Wenn Sie je CloudFront nach dem Gerät, das ein Nutzer zum Ansehen Ihrer Inhalte verwendet, unterschiedliche Versionen Ihrer Objekte zwischenspeichern möchten, empfehlen wir Ihnen, eine oder mehrere der folgenden Header so CloudFront zu konfigurieren, dass sie an Ihren benutzerdefinierten Ursprung weitergeleitet werden:
+ `CloudFront-Is-Desktop-Viewer`
+ `CloudFront-Is-Mobile-Viewer`
+ `CloudFront-Is-SmartTV-Viewer`
+ `CloudFront-Is-Tablet-Viewer`
CloudFront Legt basierend auf dem Wert des `User-Agent` Headers den Wert dieser Header auf `true` oder `false` vor der Weiterleitung der Anfrage an Ihren Ursprung fest. Wenn ein Gerät in mehr als eine Kategorie fällt, können mehrere Werte sei `true`. Beispielsweise setzt CloudFront bei einigen Tablet-Geräten möglicherweise `CloudFront-Is-Mobile-Viewer` und `CloudFront-Is-Tablet-Viewer` auf `true`. Weitere Hinweise zur Konfiguration der CloudFront Zwischenspeicherung auf der Grundlage von Anforderungsheadern finden Sie unter. [Zwischenspeichern von Inhalten auf der Grundlage von Anforderungsheadern](header-caching.md)
Sie können so konfigurieren CloudFront , dass Objekte auf der Grundlage von Werten im `User-Agent` Header zwischengespeichert werden, dies wird jedoch nicht empfohlen. Der `User-Agent` Header hat viele mögliche Werte, und das Zwischenspeichern auf der Grundlage dieser Werte würde CloudFront dazu führen, dass deutlich mehr Anfragen an Ihren Ursprung weitergeleitet werden.
Wenn Sie nicht so konfigurieren CloudFront , dass Objekte auf der Grundlage von Werten im `User-Agent` Header zwischengespeichert werden, CloudFront fügt Sie einen `User-Agent` Header mit dem folgenden Wert hinzu, bevor eine Anfrage an Ihren Ursprung weitergeleitet wird:
`User-Agent = Amazon CloudFront`
CloudFront fügt diesen Header hinzu, unabhängig davon, ob die Anfrage des Viewers einen `User-Agent` Header enthält. Wenn die Anfrage des Viewers einen `User-Agent` Header enthält, CloudFront wird dieser entfernt.
## Wie CloudFront werden Antworten von Ihrem benutzerdefinierten Ursprung verarbeitet
Erfahren Sie, wie Antworten aus Ihrer benutzerdefinierten Quelle CloudFront verarbeitet werden.
**Contents**
+ [`100 Continue` Antworten](#Response100Continue)
+ [Caching](#ResponseCustomCaching)
+ [Abgebrochene Anfragen](#response-custom-canceled-requests)
+ [Inhaltsvereinbarung](#ResponseCustomContentNegotiation)
+ [Cookies](#ResponseCustomCookies)
+ [Abgebrochene TCP-Verbindungen](#ResponseCustomDroppedTCPConnections)
+ [HTTP-Antwort-Header, die CloudFront entfernen oder ersetzen](#ResponseCustomRemovedHeaders)
+ [Maximale Dateigröße, die zwischengespeichert werden kann](#ResponseCustomMaxFileSize)
+ [Ursprung nicht verfügbar](#ResponseCustomOriginUnavailable)
+ [Umleitungen](#ResponseCustomRedirects)
+ [`Transfer-Encoding`-Header](#ResponseCustomTransferEncoding)
### `100 Continue` Antworten
Ihr Absender kann nicht mehr als eine 100-Continue-Antwort an CloudFront senden. CloudFront Erwartet nach der ersten 100-Continue-Antwort eine HTTP-200-OK-Antwort. Wenn Ihr Absender nach der ersten eine weitere 100-Continue-Antwort sendet, CloudFront wird ein Fehler zurückgegeben.
### Caching
+ Stellen Sie sicher, dass der Ursprungsserver in den Header-Feldern `Date` und `Last-Modified` gültige und korrekte Werte einsetzt.
+ CloudFront respektiert normalerweise einen `Cache-Control: no-cache` Header in der Antwort von der Quelle. Eine Ausnahme von dieser Regel wird unter [Gleichzeitige Anfragen für dasselbe Objekt (Zusammenfassung von Anfragen)](#request-custom-traffic-spikes) beschrieben.
### Abgebrochene Anfragen
Wenn sich ein Objekt nicht im Edge-Cache befindet und ein Betrachter eine Sitzung beendet (z. B. einen Browser schließt), nachdem CloudFront er das Objekt von Ihrem Ursprung abgerufen hat, aber bevor es das angeforderte Objekt liefern kann, wird das Objekt CloudFront nicht an der Edge-Position zwischengespeichert.
### Inhaltsvereinbarung
Wenn Ihr Ursprung `Vary:*` in der Antwort zurückkehrt und der Wert von **Minimum TTL** für das entsprechende Cache-Verhalten **0** ist, wird das Objekt CloudFront zwischengespeichert, aber dennoch wird jede nachfolgende Anfrage für das Objekt an den Ursprung weitergeleitet, um zu bestätigen, dass der Cache die neueste Version des Objekts enthält. CloudFront enthält keine bedingten Header wie oder. `If-None-Match` `If-Modified-Since` Infolgedessen gibt Ihr CloudFront Origin das Objekt als Antwort auf jede Anfrage zurück.
Wenn Ihr Ursprung `Vary:*` in der Antwort zurückgegeben wird und wenn der Wert von **Minimum TTL** für das entsprechende Cache-Verhalten ein anderer Wert ist, CloudFront verarbeitet der `Vary` Header wie unter beschrieben[HTTP-Antwort-Header, die CloudFront entfernen oder ersetzen](#ResponseCustomRemovedHeaders).
### Cookies
Wenn Sie Cookies für ein Cache-Verhalten aktivieren und der Ursprung Cookies mit einem Objekt zurückgibt, werden sowohl das Objekt als auch die Cookies CloudFront zwischengespeichert. Beachten Sie, dass diese Vorgehensweise die Zwischenspeicherbarkeit für ein Objekt reduziert. Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Cookies](Cookies.md).
### Abgebrochene TCP-Verbindungen
Wenn die TCP-Verbindung zwischen CloudFront und Ihrem Ursprung unterbrochen wird, während Ihr Ursprung ein Objekt zurückgibt CloudFront, hängt CloudFront das Verhalten davon ab, ob Ihr Ursprung einen `Content-Length` Header in der Antwort enthalten hat:
+ **Content-Length-Header** — CloudFront gibt das Objekt an den Betrachter zurück, sobald dieser das Objekt von Ihrem Ursprung bezieht. Wenn der Wert des `Content-Length` Headers jedoch nicht der Größe des Objekts entspricht, wird das Objekt CloudFront nicht zwischengespeichert.
+ **Transfer-Encoding: Chunked** — CloudFront gibt das Objekt so an den Betrachter zurück, wie es das Objekt von Ihrem Ursprung abgerufen hat. Wenn die Antwort in Teilen jedoch nicht vollständig ist, CloudFront wird das Objekt nicht zwischengespeichert.
+ **Kein Content-Length-Header** — CloudFront gibt das Objekt an den Viewer zurück und speichert es im Cache, aber das Objekt ist möglicherweise nicht vollständig. Ohne einen `Content-Length` Header kann CloudFront nicht bestimmen, ob die TCP-Verbindung versehentlich oder absichtlich verworfen wurde.
Wir empfehlen, dass Sie Ihren HTTP-Server so konfigurieren, dass er einen `Content-Length` Header hinzufügt, um zu verhindern, dass Teile CloudFront von Objekten zwischengespeichert werden.
### HTTP-Antwort-Header, die CloudFront entfernen oder ersetzen
CloudFront entfernt oder aktualisiert die folgenden Header-Felder, bevor die Antwort von Ihrem Ursprung an den Viewer weitergeleitet wird:
+ `Set-Cookie`— Wenn Sie CloudFront die Weiterleitung von Cookies konfigurieren, wird das `Set-Cookie` Header-Feld an Clients weitergeleitet. Weitere Informationen finden Sie unter [Zwischenspeichern von Inhalten auf der Grundlage von Cookies](Cookies.md).
+ `Trailer`
+ `Transfer-Encoding`— Wenn Ihr Origin dieses Header-Feld zurückgibt, CloudFront setzt er den Wert auf, `chunked` bevor die Antwort an den Betrachter zurückgegeben wird.
+ `Upgrade`
+ `Vary` – Beachten Sie Folgendes:
+ Wenn Sie konfigurieren CloudFront , dass einer der gerätespezifischen Header an Ihren Ursprung (`CloudFront-Is-Desktop-Viewer`,,`CloudFront-Is-Tablet-Viewer`) weitergeleitet wird `CloudFront-Is-Mobile-Viewer``CloudFront-Is-SmartTV-Viewer`, und wenn Sie Ihren Ursprung so konfigurieren, dass er CloudFront zurückkehrt CloudFront, kehrt `Vary:User-Agent` er `Vary:User-Agent` zum Viewer zurück. Weitere Informationen finden Sie unter [Konfigurieren der Zwischenspeicherung basierend auf dem Gerätetyp](header-caching.md#header-caching-web-device).
+ Wenn Sie Ihren Ursprung so konfigurieren, dass er entweder `Accept-Encoding` oder `Cookie` in den `Vary` Header CloudFront einschließt, werden die Werte in die Antwort an den Viewer aufgenommen.
+ Wenn Sie so konfigurieren, CloudFront dass Header an Ihren Ursprung weitergeleitet werden, und wenn Sie Ihren Ursprung so konfigurieren, dass die Header-Namen CloudFront in der `Vary` Kopfzeile CloudFront zurückgegeben werden (z. B.`Vary:Accept-Charset,Accept-Language`), wird der `Vary` Header mit diesen Werten an den Viewer zurückgegeben.
+ Hinweise dazu, wie ein Wert von `*` im `Vary` Header CloudFront verarbeitet wird, finden Sie unter[Inhaltsvereinbarung](#ResponseCustomContentNegotiation).
+ Wenn Sie Ihren Ursprung so konfigurieren, dass er andere Werte in den `Vary` Header einbezieht, CloudFront werden die Werte entfernt, bevor die Antwort an den Viewer zurückgegeben wird.
+ `Via`— CloudFront setzt den Wert in der Antwort an den Betrachter auf den folgenden Wert:
`Via: `*http-version* *alphanumeric-string*`.cloudfront.net (CloudFront)`
Der Wert ist beispielsweise wie folgt:
`Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)`
### Maximale Dateigröße, die zwischengespeichert werden kann
Die maximale Größe eines Antworttextes, der in seinem Cache CloudFront gespeichert wird, beträgt 50 GB. Dazu gehören auch Antworten für aufgeteilte Übertragungen, in denen kein Wert für die `Content-Length`-Kopfzeile angegeben wurde.
Sie können ein Objekt zwischenspeichern, das größer als diese Größe ist, indem Sie Bereichsanforderungen verwenden, um die Objekte in Teilen anzufordern, die jeweils 50 GB oder weniger groß sind. CloudFront CloudFrontspeichert diese Teile im Cache, da jeder von ihnen 50 GB oder weniger groß ist. Nachdem der Viewer alle Teile des Objekts abgerufen hat, kann er das ursprüngliche, größere Objekt rekonstruieren. Weitere Informationen finden Sie unter [Verwenden von Bereichsanforderungen zum Zwischenspeichern großer Objekte](RangeGETs.md#cache-large-objects-with-range-requests).
### Ursprung nicht verfügbar
Wenn Ihr Ursprungsserver nicht verfügbar ist und eine Anfrage für ein Objekt CloudFront erhält, das sich im Edge-Cache befindet, aber abgelaufen ist (z. B. weil der in der `Cache-Control max-age` Direktive angegebene Zeitraum abgelaufen ist), wird CloudFront entweder die abgelaufene Version des Objekts oder eine benutzerdefinierte Fehlerseite bereitgestellt. Weitere Informationen zum CloudFront Verhalten bei der Konfiguration benutzerdefinierter Fehlerseiten finden Sie unter[Wie CloudFront werden Fehler verarbeitet, wenn Sie benutzerdefinierte Fehlerseiten konfiguriert haben](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
In einigen Fällen wird ein Objekt, das selten angefordert wird, entfernt und ist nicht mehr im Edge-Cache verfügbar. CloudFront kann ein Objekt, das entfernt wurde, nicht bereitstellen.
### Umleitungen
Wenn Sie den Speicherort eines Objekts auf dem Ursprungsserver ändern, können Sie Ihren Webserver so konfigurieren, dass Anfragen an den neuen Speicherort umgeleitet werden. Nachdem Sie die Umleitung konfiguriert haben, sendet ein Betrachter, wenn er zum ersten Mal eine Anfrage für das Objekt CloudFront sendet, die Anfrage an den Ursprung, und der Absender antwortet mit einer Weiterleitung (z. B.). `302 Moved Temporarily` CloudFront speichert die Weiterleitung im Cache und gibt sie an den Betrachter zurück. CloudFront folgt der Weiterleitung nicht.
Sie können Ihren Webserver so konfigurieren, dass Anfragen an einen der folgenden Speicherorte umgeleitet werden:
+ Die neue URL des Objekts auf dem Ursprungsserver. Wenn der Zuschauer der Weiterleitung zur neuen URL folgt, umgeht er die URL CloudFront und geht direkt zum Ursprung. Daher empfehlen wir, Anforderungen nicht an die neue URL des Objekts auf dem Ursprungsserver weiterzuleiten.
+ Die neue CloudFront URL für das Objekt. Wenn der Betrachter die Anfrage sendet, die die neue CloudFront URL enthält, CloudFront ruft er das Objekt von der neuen Position auf Ihrem Ursprung ab, speichert es am Edge-Standort im Cache und gibt das Objekt an den Viewer zurück. Nachfolgende Anfragen für das Objekt werden von dem Edge-Standort bedient. Dadurch werden Latenzzeiten und Arbeitslasten vermieden, die bei Viewer-Anforderungen für das Objekt an den Ursprungsserver entstehen. Allerdings fallen bei jeder neuen Anfrage für das Objekt Gebühren für zwei Anfragen an CloudFront berechnet.
### `Transfer-Encoding`-Header
CloudFront unterstützt nur den `chunked` Wert des Headers. `Transfer-Encoding` Wenn Ihr Ursprung CloudFront zurückkehrt`Transfer-Encoding: chunked`, sendet er das Objekt an den Client zurück, sobald es am Edge-Standort empfangen wurde, und speichert das Objekt für nachfolgende Anfragen im Chunk-Format.
Wenn der Betrachter eine `Range GET` Anfrage stellt und der Ursprung CloudFront zurückkehrt`Transfer-Encoding: chunked`, wird das gesamte Objekt anstelle des angeforderten Bereichs an den Viewer zurückgegeben.
Wir empfehlen, dass Sie die Abschnittscodierung verwenden, wenn die Länge des Inhalts Ihrer Antwort nicht im Voraus ermittelt werden kann. Weitere Informationen finden Sie unter [Abgebrochene TCP-Verbindungen](#ResponseCustomDroppedTCPConnections).
# Verhalten von Anfragen und Antworten für Ursprungsgruppen
Anfragen an eine Ursprungsgruppe funktionieren genauso wie Anfragen an einen Ursprung, der nicht als Ursprungsgruppe eingerichtet ist, außer wenn ein Ursprungs-Failover vorliegt. Wie bei jeder anderen Quelle gilt: Wenn CloudFront eine Anfrage eingeht und der Inhalt bereits an einem Edge-Speicherort zwischengespeichert ist, wird der Inhalt den Zuschauern aus dem Cache bereitgestellt. Wenn ein Cache-Fehler vorliegt und der Ursprung eine Ursprungsgruppe ist, werden Viewer-Anforderungen an den primären Ursprung in der Ursprungsgruppe weitergeleitet.
Das Anfrage- und Antwortverhalten für den primären Ursprung ist identisch mit dem für einen Ursprung, der nicht zu einer Ursprungsgruppe gehört. Weitere Informationen erhalten Sie unter [Verhalten von Anfragen und Antworten für Amazon-S3-Ursprünge](RequestAndResponseBehaviorS3Origin.md) und [Verhalten von Anfragen und Antworten für benutzerdefinierte Ursprungsserver](RequestAndResponseBehaviorCustomOrigin.md).
Nachfolgend werden die Verhaltensweisen bei Origin Failover beschrieben, wenn der primäre Ursprung bestimmte HTTP-Statuscodes ausgibt:
+ HTTP 2xx-Statuscode (erfolgreich): Die Datei wird CloudFront zwischengespeichert und an den Betrachter zurückgegeben.
+ HTTP 3xx-Statuscode (Umleitung): CloudFront Gibt den Statuscode an den Betrachter zurück.
+ HTTP 4xx- oder 5xx-Statuscode (Client-/Server-Fehler): Wenn der zurückgegebene Statuscode für Failover konfiguriert wurde, wird dieselbe Anfrage an den sekundären Ursprung in der Ursprungsgruppe CloudFront gesendet.
+ HTTP 4xx- oder 5xx-Statuscode (Client-/Server-Fehler): Wenn der zurückgegebene Statuscode nicht für Failover konfiguriert wurde, wird der Fehler an den Viewer zurückgegeben. CloudFront
CloudFront führt nur dann einen Failover zum sekundären Ursprung durch, wenn die HTTP-Methode der Viewer-Anfrage,, oder ist. `GET` `HEAD` `OPTIONS` CloudFront führt nicht zu einem Failover, wenn der Betrachter eine andere HTTP-Methode sendet (z. B. `POST``PUT`, usw.).
Wenn eine Anfrage CloudFront an einen sekundären Ursprung gesendet wird, ist das Antwortverhalten dasselbe wie bei einem CloudFront Ursprung, der sich nicht in einer Ursprungsgruppe befindet.
Weitere Informationen zu Ursprungsgruppen finden Sie unter [Optimieren der Hochverfügbarkeit mit CloudFront Origin Failover](high_availability_origin_failover.md).
# Hinzufügen benutzerdefinierter Header zu Ursprungsanforderungen
Sie können CloudFront so konfigurieren, dass den Anforderungen, die an den Ursprung gesendet werden, benutzerdefinierte Header hinzugefügt werden. Mit benutzerdefinierten Headern können Sie Informationen aus Ihrem Ursprung senden und erfassen, die Sie mit typischen Viewer-Anforderungen nicht erhalten. Sie können diese Header sogar für jeden Ursprung anpassen. CloudFront unterstützt benutzerdefinierte Header für benutzerdefinierte Ursprünge und für Amazon-S3-Ursprünge.
**Contents**
+ [Anwendungsfälle](#add-origin-custom-headers-use-cases)
+ [Konfigurieren von CloudFront zum Hinzufügen von benutzerdefinierten Headern zu Ursprungsanforderungen](#add-origin-custom-headers-configure)
+ [Benutzerdefinierte Header, die CloudFront nicht zu Ursprungsanforderungen hinzufügen kann](#add-origin-custom-headers-denylist)
+ [Konfigurieren von CloudFront zur Weiterleitung des `Authorization`-Headers](#add-origin-custom-headers-forward-authorization)
## Anwendungsfälle
Sie können benutzerdefinierte Header wie in den folgenden Beispielen verwenden:
**Identifizierung von Anforderungen von CloudFront**
Sie können die Anforderungen identifizieren, die Ihr Ursprung von CloudFront erhält. Dies kann nützlich sein, wenn Sie wissen möchten, ob Benutzer CloudFront umgehen oder mehr als einen CDN verwenden, und Informationen dazu erhalten möchten, welche Anforderungen aus welchem CDN stammen.
Wenn Sie einen Amazon S3-Ursprung verwenden und die [Protokollierung des Zugriffs auf Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html) aktivieren, enthalten die Protokolle keine Header-Informationen.
**Bestimmen, welche Anforderungen von einer bestimmten Verteilung stammen**
Wenn Sie mehrere CloudFront-Verteilungen für die Verwendung desselben Ursprungs konfigurieren, können Sie jeder Verteilung verschiedene benutzerdefinierte Header hinzufügen. Anschließend können Sie anhand der Protokolle Ihres Ursprungs ermitteln, welche Anforderungen aus welcher CloudFront-Verteilung stammen.
**Cross-Origin Resource Sharing (CORS) aktivieren**
Wenn einige Betrachter keine ursprungsübergreifende Ressourcenfreigabe (Cross-Origin Resource Sharing, CORS) unterstützen, können Sie CloudFront so konfigurieren, dass der `Origin`-Header den an den Ursprung gesendeten Anforderungen stets hinzugefügt werden. Dann können Sie Ihren Ursprung so konfigurieren, dass der `Access-Control-Allow-Origin`-Header für jede Anforderung zurückgegeben wird. Sie müssen außerdem [CloudFront für die Beachtung von CORS-Einstellungen konfigurieren](header-caching.md#header-caching-web-cors).
**Steuern des Zugriffs auf Inhalt**
Mit benutzerdefinierten Header können Sie den Zugriff auf Inhalte steuern. Wenn Sie den Ursprung so konfigurieren, dass er nur auf Anforderungen reagiert, die einen von CloudFront hinzugefügten Header enthalten, verhindern Sie, dass Benutzer CloudFront umgehen und direkt am Ursprung auf Ihre Inhalte zugreifen. Weitere Informationen finden Sie unter [Beschränken des Zugriffs auf Dateien auf benutzerdefinierten Ursprungsservern](private-content-overview.md#forward-custom-headers-restrict-access).
## Konfigurieren von CloudFront zum Hinzufügen von benutzerdefinierten Headern zu Ursprungsanforderungen
Um eine Verteilung so zu konfigurieren, dass benutzerdefinierte Header Anforderungen hinzugefügt werden, die er an Ihren Ursprung sendet, aktualisieren Sie die Ursprungskonfiguration mit einer der folgenden Methoden:
+ **CloudFront-Konsole** – Wenn Sie eine Distribution erstellen oder aktualisieren, geben Sie in den Einstellungen für **Benutzerdefinierte Ursprungsheader** die Header-Namen und -Werte an. Weitere Informationen finden Sie unter [Benutzerdefinierten Header hinzufügen](DownloadDistValuesOrigin.md#DownloadDistValuesOriginCustomHeaders).
+ **CloudFront-API** – Geben Sie für jeden Ursprung, dem Sie benutzerdefinierte Header hinzufügen möchten, die Header-Namen und -Werte im `CustomHeaders`-Feld in `Origin` an. Weitere Informationen finden Sie unter [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html) oder [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) in der *API-Referenz für Amazon CloudFront*.
Wenn die Header-Namen und -Werte, die Sie angeben, nicht bereits in der Anforderung des Betrachters vorhanden sind, fügt CloudFront sie der Ursprungsanforderung hinzu. Wenn ein Header vorhanden ist, überschreibt CloudFront den Header-Wert, bevor die Anforderung an den Ursprung weitergeleitet wird.
Informationen zu den Kontingenten für benutzerdefinierte Ursprungsheader finden Sie unter [Kontingente für Header](cloudfront-limits.md#limits-custom-headers).
## Benutzerdefinierte Header, die CloudFront nicht zu Ursprungsanforderungen hinzufügen kann
Sie können CloudFront nicht zum Hinzufügen der die folgenden Header zu Anforderungen konfigurieren, die an den Ursprung gesendet werden:
+ `Cache-Control`
+ `Connection`
+ `Content-Length`
+ `Cookie`
+ `Host`
+ `If-Match`
+ `If-Modified-Since`
+ `If-None-Match`
+ `If-Range`
+ `If-Unmodified-Since`
+ `Max-Forwards`
+ `Pragma`
+ `Proxy-Authenticate`
+ `Proxy-Authorization`
+ `Proxy-Connection`
+ `Range`
+ `Request-Range`
+ `TE`
+ `Trailer`
+ `Transfer-Encoding`
+ `Upgrade`
+ `Via`
+ Header, die mit beginnen `X-Amz-`
+ Header, die mit beginnen `X-Edge-`
+ `X-Real-Ip`
## Konfigurieren von CloudFront zur Weiterleitung des `Authorization`-Headers
Wenn Cloudfront eine Betrachteranfragen an den Ursprung weiterleitet, entfernt CloudFront standardmäßig einige Betrachter-Header einschließlich des `Authorization`-Headers. Um sicherzustellen, dass Ihr Ursprung immer den `Authorization`-Header in Ursprungsanforderungen erhält, haben Sie folgende Möglichkeiten:
+ Fügen Sie den `Authorization`-Header mithilfe einer Cache-Richtlinie zum Cache-Schlüssel hinzu. Alle Header im Cache-Schlüssel werden automatisch in Ursprungsanforderungen eingeschlossen. Weitere Informationen finden Sie unter [Steuern des Cache-Schlüssels mit einer Richtlinie](controlling-the-cache-key.md).
+ Verwenden Sie eine Herkunftsanforderungsrichtlinie, die alle Betrachter-Header an den Ursprung weiterleitet. Sie können den `Authorization`-Header nicht einzeln in einer Herkunftsanforderungsrichtlinie weiterleiten, aber wenn Sie alle Betrachter-Header weiterleiten, enthält CloudFront den `Authorization`-Header in Betrachteranfragen. CloudFront bietet eine Richtlinie für die Anforderung des verwalteten Ursprungs für diesen Anwendungsfall, die als **Managed-AllViewer** bezeichnet wird. Weitere Informationen finden Sie unter [Verwenden verwalteter Ursprungsanforderungsrichtlinien](using-managed-origin-request-policies.md).
# Wie CloudFront werden Teilanfragen für ein Objekt (BereichGETs) verarbeitet
Bei großen Objekten kann der Viewer (Webbrowser oder anderer Client) mehrere `GET`-Anforderungen stellen und verwendet den `Range`-Anforderungs-Header, um das Objekt in kleineren Teilen herunterzuladen. Diese Anfragen für Bereiche von Bytes, manchmal auch als `Range GET`-Anfragen bezeichnet, steigern die Effizienz von Teil-Downloads und die Wiederherstellung nach teilweise fehlgeschlagenen Übertragungen.
Wenn es eine `Range GET` Anfrage CloudFront empfängt, überprüft es den Cache an dem Edge-Standort, der die Anfrage empfangen hat. Wenn der Cache an dieser Edge-Position bereits das gesamte Objekt oder den angeforderten Teil des Objekts enthält, wird CloudFront sofort der angeforderte Bereich aus dem Cache bereitgestellt.
Wenn der Cache den angeforderten Bereich nicht enthält, CloudFront wird die Anfrage an den Ursprung weitergeleitet. (Um die Leistung zu optimieren, wird CloudFront möglicherweise ein größerer Bereich angefordert, als der Client im angefordert hat`Range GET`.) Der nächste Schritt hängt davon ab, ob der Ursprung `Range GET`-Anfragen unterstützt:
+ **Wenn der Ursprung `Range GET` Anfragen unterstützt**, gibt er den angeforderten Bereich zurück. CloudFront bedient den angeforderten Bereich und speichert ihn auch für future Anfragen. (Amazon S3 unterstützt `Range GET`-Anforderungen, ebenso wie viele HTTP-Server.)
+ **Wenn der Ursprung keine `Range GET` Anfragen unterstützt**, wird das gesamte Objekt zurückgegeben. CloudFront bedient die aktuelle Anfrage, indem es das gesamte Objekt sendet und es gleichzeitig für future Anfragen zwischenspeichert. Nachdem CloudFront das gesamte Objekt in einem Edge-Cache zwischengespeichert wurde, reagiert es auf neue `Range GET` Anfragen, indem es den angeforderten Bereich bereitstellt.
In beiden Fällen CloudFront beginnt die Bereitstellung des angeforderten Bereichs oder Objekts für den Endbenutzer, sobald das erste Byte vom Ursprung eintrifft.
**Anmerkung**
Wenn der Betrachter eine `Range GET` Anfrage stellt und der Ursprung CloudFront zurückkehrt`Transfer-Encoding: chunked`, wird das gesamte Objekt anstelle des angeforderten Bereichs an den Betrachter zurückgegeben.
CloudFront folgt im Allgemeinen der RFC-Spezifikation für den `Range` Header. Wenn Ihre `Range`-Header die folgenden Anforderungen jedoch nicht erfüllen, gibt CloudFront HTTP-Statuscode `200` mit dem vollständigen Objekt anstelle von Statuscode `206` mit den angefragten Bereichen zurück:
+ Die Bereiche müssen in aufsteigender Reihenfolge aufgeführt sein. Beispielweise ist `100-200,300-400` gültig, `300-400,100-200` hingegen nicht.
+ Die Bereiche dürfen sich nicht überschneiden. Beispielsweise ist `100-200,150-250` nicht gültig.
+ Alle Bereichsspezifikationen müssen gültig sein. Beispielsweise können Sie keinen negativen Wert als Teil eines Bereichs angeben.
Weitere Informationen zum `Range`-Anforderungs-Header finden Sie im Abschnitt zu [Bereichsanforderungen](https://httpwg.org/specs/rfc7233.html#range.requests) in RFC 7233 oder im Abschnitt zum [Bereich](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) in den MDN-Webdokumenten.
## Verwenden von Bereichsanforderungen zum Zwischenspeichern großer Objekte
Wenn das Caching aktiviert ist, wird ein Objekt, das größer als 50 GB ist, CloudFront nicht abgerufen oder zwischengespeichert. Wenn ein Ursprung angibt, dass das Objekt größer als diese Größe ist (im `Content-Length` Antwort-Header), CloudFront wird die Verbindung zum Ursprung geschlossen und es wird ein Fehler an den Viewer zurückgegeben. ( CloudFront Kann bei deaktiviertem Caching ein Objekt, das größer als diese Größe ist, vom Ursprung abrufen und an den Betrachter weitergeben. Zwischenspeichert das Objekt jedoch CloudFront nicht.)
Bei Bereichsanforderungen können CloudFront Sie jedoch ein Objekt zwischenspeichern, das größer als die [maximale zwischenspeicherbare Dateigröße](cloudfront-limits.md#limits-web-distributions) ist.
**Example Beispiel**
1. Gehen wir von einem Ursprung mit einem Objekt mit 100 GB aus. Wenn das Caching aktiviert ist, CloudFront wird ein so großes Objekt nicht abgerufen oder zwischengespeichert. Der Viewer kann jedoch mehrere Bereichsanforderungen senden, um dieses Objekt in Teilen abzurufen, wobei die Teile jeweils kleiner als 50 GB sind.
1. Der Viewer kann das Objekt in 20-GB-Teilen anfordern, indem er eine Anforderung mit dem Header `Range: bytes=0-21474836480` sendet, um den ersten Teil abzurufen, eine weitere Anforderung mit dem Header `Range: bytes=21474836481-42949672960`, um den nächsten Teil abzurufen und so weiter.
1. Nachdem der Viewer alle Teile empfangen hat, kann er sie kombinieren, um das ursprüngliche Objekt mit 100 GB zu erstellen.
1. In diesem Fall werden alle 20 GB-Teile des Objekts CloudFront zwischengespeichert und es kann auf nachfolgende Anfragen für denselben Teil aus dem Cache reagiert werden.
Bei einer Bereichsanforderung für ein komprimiertes Objekt basiert der angeforderte Bytebereich auf der komprimierten Größe und nicht auf der Originalgröße des Objekts. Weitere Informationen zur Komprimierung von Dateien finden Sie unter [Bereitstellen von komprimierten Dateien](ServingCompressedFiles.md).
# Wie CloudFront werden HTTP 3xx-Statuscodes von Ihrem Ursprung verarbeitet
Wenn Sie CloudFront ein Objekt von Ihrem Amazon S3 S3-Bucket oder Ihrem benutzerdefinierten Ursprungsserver anfordern, gibt Ihr Origin manchmal einen HTTP 3xx-Statuscode zurück. Dies weist in der Regel auf einen der folgenden Umstände hin:
+ Die URL des Objekts hat sich geändert (z. B. Statuscodes 301, 302, 307 oder 308).
+ Das Objekt hat sich seit der letzten CloudFront Anfrage nicht geändert (Statuscode 304)
CloudFront speichert 3xx-Antworten entsprechend den Einstellungen in Ihrer CloudFront Distribution und den Headern in der Antwort im Cache. CloudFront speichert die Antworten 307 und 308 nur dann im Cache, wenn Sie den `Cache-Control` Header in die Antworten von der Quelle aufnehmen. Weitere Informationen finden Sie unter [Verwalten der Dauer, die Inhalte im Cache bleiben (Ablauf)](Expiration.md).
Wenn dein Absender einen Umleitungsstatuscode zurückgibt (z. B. 301 oder 307), folgt er der Weiterleitung CloudFront nicht. CloudFront leitet die 301- oder 307-Antwort an den Zuschauer weiter, der der Weiterleitung folgen kann, indem er eine neue Anfrage sendet.
# Wie CloudFront werden die HTTP-Statuscodes 4xx und 5xx von Ihrem Ursprung verarbeitet
Wenn CloudFront Sie ein Objekt von Ihrem Amazon S3 S3-Bucket oder Ihrem benutzerdefinierten Ursprungsserver anfordern, gibt Ihr Origin manchmal einen HTTP-Statuscode 4xx oder 5xx zurück, der darauf hinweist, dass ein Fehler aufgetreten ist. CloudFront Das Verhalten hängt ab von:
+ ob Sie benutzerdefinierte Fehlerseiten konfiguriert haben
+ Ob Sie konfiguriert haben, wie lange Sie Fehlerantworten von Ihrem Ursprung zwischenspeichern CloudFront möchten (Mindest-TTL beim Zwischenspeichern von Fehlern)
+ dem Statuscode
+ Bei 5xx-Statuscodes, ob sich das angeforderte Objekt derzeit im Edge-Cache befindet CloudFront
+ bei einigen 4xx-Statuscodes, ob der Ursprung einen `Cache-Control max-age`- oder `Cache-Control s-maxage`-Header zurückgibt
CloudFront speichert immer Antworten auf `GET` und `HEAD` Anfragen im Cache. Sie können auch so konfigurieren CloudFront , dass Antworten auf `OPTIONS` Anfragen zwischengespeichert werden. CloudFront speichert Antworten auf Anfragen, die die anderen Methoden verwenden, nicht im Cache.
Wenn der Ursprung nicht antwortet, wird bei der CloudFront Anfrage an den Ursprung ein Timeout erreicht, was als HTTP 5xx-Fehler des Ursprungs angesehen wird, obwohl der Ursprung nicht mit diesem Fehler geantwortet hat. In diesem Szenario werden CloudFront weiterhin zwischengespeicherte Inhalte bereitgestellt. Weitere Informationen finden Sie unter [Ursprung nicht verfügbar](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomOriginUnavailable).
Wenn Sie die Protokollierung aktiviert haben, werden die Ergebnisse unabhängig vom HTTP-Statuscode in die Protokolle CloudFront geschrieben.
Weitere Informationen zu Funktionen und Optionen, die sich auf die Fehlermeldung beziehen CloudFront, von der zurückgegeben wurde, finden Sie im Folgenden:
+ Informationen zu Einstellungen für benutzerdefinierte Fehlerseiten in der CloudFront Konsole finden Sie unter[Benutzerdefinierte Fehlerseiten und Zwischenspeicherung von Fehlern](DownloadDistValuesErrorPages.md).
+ Hinweise zum Fehler beim Zwischenspeichern der Mindest-TTL in der CloudFront Konsole finden Sie unter. [Mindest-TTL für die Zwischenspeicherung von Fehlern (Sekunden)](DownloadDistValuesErrorPages.md#DownloadDistValuesErrorCachingMinTTL)
+ Eine Liste der HTTP-Statuscodes, die CloudFront zwischengespeichert werden, finden Sie unter. [Die HTTP-Statuscodes 4xx und 5xx, die zwischengespeichert werden CloudFront](#HTTPStatusCodes-cached-errors)
**Topics**
+ [Wie CloudFront werden Fehler verarbeitet, wenn Sie benutzerdefinierte Fehlerseiten konfiguriert haben](#HTTPStatusCodes-custom-error-pages)
+ [Wie CloudFront werden Fehler verarbeitet, wenn Sie keine benutzerdefinierten Fehlerseiten konfiguriert haben](#HTTPStatusCodes-no-custom-error-pages)
+ [Die HTTP-Statuscodes 4xx und 5xx, die zwischengespeichert werden CloudFront](#HTTPStatusCodes-cached-errors)
## Wie CloudFront werden Fehler verarbeitet, wenn Sie benutzerdefinierte Fehlerseiten konfiguriert haben
Wenn Sie benutzerdefinierte Fehlerseiten konfiguriert haben, hängt CloudFront das Verhalten davon ab, ob sich das angeforderte Objekt im Edge-Cache befindet.
### Das angeforderte Objekt ist nicht im Edge-Cache vorhanden
CloudFront versucht weiterhin, das angeforderte Objekt von Ihrem Ursprung abzurufen, wenn alle der folgenden Bedingungen zutreffen:
+ Ein Viewer fordert ein Objekt an.
+ Das Objekt ist nicht im Edge-Cache vorhanden.
+ Ihr Ursprungsserver gibt einen HTTP-Statuscode 4xx oder 5xx zurück und eines der Folgenden ist wahr:
+ Ihr Ursprungsserver gibt einen HTTP-Statuscode 5xx anstelle eines Statuscodes 304 (nicht geändert) oder eine aktualisierte Version des Objekts zurück.
+ Ihr Ursprungs-Server gibt einen HTTP-Statuscode 4xx zurück, der nicht durch einen Cache-Control-Header eingeschränkt und in der folgenden Statuscodeliste enthalten is: [Die HTTP-Statuscodes 4xx und 5xx, die zwischengespeichert werden CloudFront](#HTTPStatusCodes-cached-errors).
+ Ihr Ursprungsserver gibt einen HTTP-Statuscode 4xx mit einem `Cache-Control max-age`- oder `Cache-Control s-maxage`-Header zurück und der Statuscode ist in der folgenden Statuscodeliste enthalten: [HTTP 4xx-Statuscodes, die basierend auf CloudFront Headern zwischengespeichert werden `Cache-Control`](#HTTPStatusCodes-cached-errors-with-cache-control).
**CloudFront macht Folgendes:**
1. CloudFront Überprüft im CloudFront Edge-Cache, der die Viewer-Anfrage empfangen hat, Ihre Distributionskonfiguration und ruft den Pfad der benutzerdefinierten Fehlerseite ab, die dem Statuscode entspricht, den Ihr Origin zurückgegeben hat.
1. CloudFront findet das erste Cache-Verhalten in Ihrer Distribution, dessen Pfadmuster dem Pfad der benutzerdefinierten Fehlerseite entspricht.
1. Der CloudFront Edge-Standort sendet eine Anforderung für die benutzerdefinierte Fehlerseite an den Ursprung, der im Cache-Verhalten angegeben ist.
1. Der Ursprungsserver gibt die benutzerdefinierte Fehlerseite an den Edge-Standort zurück.
1. CloudFront gibt die benutzerdefinierte Fehlerseite an den Viewer zurück, der die Anfrage gestellt hat, und speichert die benutzerdefinierte Fehlerseite für maximal die folgenden Werte im Cache:
+ Der Zeitraum, der durch die Mindest-TTL für die Zwischenspeicherung von Fehlern angegeben ist (standardmäßig zehn Sekunden)
+ Der Zeitraum, der durch einen `Cache-Control max-age`- oder einen `Cache-Control s-maxage`-Header angegeben ist, der vom Ursprungsserver zurückgegeben wird, wenn die erste Anfrage den Fehler generiert hat
1. Nach Ablauf der (in Schritt 5 festgelegten) Cache-Zeit wird erneut CloudFront versucht, das angeforderte Objekt abzurufen, indem eine weitere Anfrage an Ihren Ursprung weitergeleitet wird. CloudFront wiederholt den Vorgang in Intervallen, die durch die Mindest-TTL für das Zwischenspeichern des Fehlers festgelegt sind.
**Anmerkung**
Wenn Sie auch ein Cache-Verhalten für dieselbe benutzerdefinierte Fehlerseite konfiguriert haben, CloudFront verwendet stattdessen das Cache-Verhalten TTL. In diesem Fall gehen CloudFront Sie für die Schritte 5 und 6 wie folgt vor:
After CloudFront gibt die benutzerdefinierte Fehlerseite an den Viewer zurück, der die Anfrage gestellt hat, und CloudFront überprüft das Verhalten des Cache TTL (Sie legen beispielsweise die Standard-TTL auf 5 Sekunden fest). CloudFront speichert dann die benutzerdefinierte Fehlerseite bis zu diesem Maximum im Cache.
CloudFront Ruft die benutzerdefinierte Fehlerseite nach Ablauf von 5 Sekunden erneut vom Ursprung ab. CloudFront versucht es weiterhin in Intervallen, die durch das Cache-Verhalten (TTL) angegeben sind.
Weitere Informationen finden Sie unter [TTL-Einstellungen](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL) für das Cacheverhalten.
### Das angeforderte Objekt ist im Edge-Cache vorhanden
CloudFront bedient weiterhin das Objekt, das sich derzeit im Edge-Cache befindet, wenn alle der folgenden Bedingungen zutreffen:
+ Ein Viewer fordert ein Objekt an.
+ Das Objekt ist im Edge-Cache vorhanden, aber es ist abgelaufen.
+ Ihr Ursprungsserver gibt einen HTTP-Statuscode 5xx anstelle eines Statuscodes 304 (nicht geändert) oder eine aktualisierte Version des Objekts zurück.
**CloudFront macht Folgendes:**
1. Wenn Ihr Origin einen 5xx-Statuscode zurückgibt, CloudFront wird das Objekt bereitgestellt, obwohl es abgelaufen ist. Reagiert für die Dauer des Fehler-Cachings (Mindest-TTL) CloudFront weiterhin auf Viewer-Anfragen, indem das Objekt aus dem Edge-Cache bereitgestellt wird.
Wenn Ihr Ursprungsserver einen 4xx-Statuscode zurückgibt, sendet CloudFront den Statuscode anstelle des angeforderten Objekts an den Betrachter.
1. Wenn die Mindest-TTL für den Fehler beim Zwischenspeichern abgelaufen ist, wird erneut CloudFront versucht, das angeforderte Objekt abzurufen, indem eine weitere Anfrage an Ihren Ursprung weitergeleitet wird. Beachten Sie, dass das Objekt, wenn es nicht häufig angefordert wird, CloudFront möglicherweise aus dem Edge-Cache entfernt wird, während Ihr Ursprungsserver immer noch 5xx-Antworten zurückgibt. Informationen darüber, wie lange Objekte in CloudFront Edge-Caches verbleiben, finden Sie unter. [Verwalten der Dauer, die Inhalte im Cache bleiben (Ablauf)](Expiration.md)
## Wie CloudFront werden Fehler verarbeitet, wenn Sie keine benutzerdefinierten Fehlerseiten konfiguriert haben
Wenn Sie keine benutzerdefinierten Fehlerseiten konfiguriert haben, hängt CloudFront das Verhalten davon ab, ob sich das angeforderte Objekt im Edge-Cache befindet.
**Topics**
+ [Das angeforderte Objekt ist nicht im Edge-Cache vorhanden](#HTTPStatusCodes-no-custom-error-pages-not-in-cache)
+ [Das angeforderte Objekt ist im Edge-Cache vorhanden](#HTTPStatusCodes-no-custom-error-pages-in-cache)
### Das angeforderte Objekt ist nicht im Edge-Cache vorhanden
CloudFront versucht weiterhin, das angeforderte Objekt von Ihrem Ursprung abzurufen, wenn alle der folgenden Bedingungen zutreffen:
+ Ein Viewer fordert ein Objekt an.
+ Das Objekt ist nicht im Edge-Cache vorhanden.
+ Ihr Ursprungsserver gibt einen HTTP-Statuscode 4xx oder 5xx zurück und eines der Folgenden ist wahr:
+ Ihr Ursprungsserver gibt einen HTTP-Statuscode 5xx anstelle eines Statuscodes 304 (nicht geändert) oder eine aktualisierte Version des Objekts zurück.
+ Ihr Ursprungs-Server gibt einen HTTP-Statuscode 4xx zurück, der nicht durch einen Cache-Control-Header eingeschränkt und in der folgenden Statuscodeliste enthalten is: [Die HTTP-Statuscodes 4xx und 5xx, die zwischengespeichert werden CloudFront](#HTTPStatusCodes-cached-errors)
+ Ihr Ursprungsserver gibt einen HTTP-Statuscode 4xx mit einem `Cache-Control max-age`- oder `Cache-Control s-maxage`-Header zurück und der Statuscode ist in der folgenden Statuscodeliste enthalten: [HTTP 4xx-Statuscodes, die basierend auf CloudFront Headern zwischengespeichert werden `Cache-Control`](#HTTPStatusCodes-cached-errors-with-cache-control).
CloudFront macht Folgendes:
1. CloudFront gibt den 4xx- oder 5xx-Statuscode an den Viewer zurück und speichert außerdem den Statuscode im Edge-Cache, der die Anforderung für maximal die folgenden Werte erhalten hat:
+ Der Zeitraum, der durch die Mindest-TTL für die Zwischenspeicherung von Fehlern angegeben ist (standardmäßig zehn Sekunden)
+ Der Zeitraum, der durch einen `Cache-Control max-age`- oder einen `Cache-Control s-maxage`-Header angegeben ist, der vom Ursprungsserver zurückgegeben wird, wenn die erste Anfrage den Fehler generiert hat
1. Für die Dauer der Zwischenspeicherung (in Schritt 1 bestimmt) reagiert CloudFront auf nachfolgende Viewer-Anfragen für dasselbe Objekte mit den zwischengespeicherten Statuscodes 4xx und 5xx.
1. Nach Ablauf der (in Schritt 1 festgelegten) Caching-Zeit wird erneut CloudFront versucht, das angeforderte Objekt abzurufen, indem eine weitere Anfrage an Ihren Ursprung weitergeleitet wird. CloudFront wiederholt den Vorgang in Intervallen, die durch die Mindest-TTL für das Zwischenspeichern des Fehlers festgelegt sind.
### Das angeforderte Objekt ist im Edge-Cache vorhanden
CloudFront bedient weiterhin das Objekt, das sich derzeit im Edge-Cache befindet, wenn alle der folgenden Bedingungen zutreffen:
+ Ein Viewer fordert ein Objekt an.
+ Das Objekt ist im Edge-Cache vorhanden, aber es ist abgelaufen. Das bedeutet, dass das Objekt *veraltet* ist.
+ Ihr Ursprungsserver gibt einen HTTP-Statuscode 5xx anstelle eines Statuscodes 304 (nicht geändert) oder eine aktualisierte Version des Objekts zurück.
CloudFront macht Folgendes:
1. Wenn Ihr Origin einen 5xx-Fehlercode zurückgibt, CloudFront wird das Objekt versendet, obwohl es abgelaufen ist. Reagiert für die Dauer des Fehler-Cachings (mindestens TTL) (standardmäßig 10 Sekunden) CloudFront weiterhin auf Viewer-Anfragen, indem das Objekt aus dem Edge-Cache bereitgestellt wird.
Wenn Ihr Ursprungsserver einen 4xx-Statuscode zurückgibt, sendet CloudFront den Statuscode anstelle des angeforderten Objekts an den Betrachter.
1. Nachdem die Mindest-TTL beim Zwischenspeichern des Fehlers abgelaufen ist, wird erneut CloudFront versucht, das angeforderte Objekt abzurufen, indem eine weitere Anfrage an Ihren Ursprung weitergeleitet wird. Wenn das Objekt nicht häufig angefordert wird, wird es CloudFront möglicherweise aus dem Edge-Cache entfernt, während Ihr Ursprungsserver immer noch 5xx-Antworten zurückgibt. Weitere Informationen finden Sie unter [Verwalten der Dauer, die Inhalte im Cache bleiben (Ablauf)](Expiration.md).
**Tipp**
Wenn Sie die Direktive `Stale-While-Revalidate` oder `stale-if-error` konfigurieren, können Sie angeben, wie lange die veralteten Objekte im Edge-Cache verfügbar sein sollen. Auf diese Weise können Sie Ihren Viewern auch dann Inhalte bereitstellen, auch wenn Ihr Ursprung nicht verfügbar ist. Weitere Informationen finden Sie unter [Bereitstellung veralteter (abgelaufener) Inhalte](Expiration.md#stale-content).
CloudFront [bedient nur Objekte, die bis zum angegebenen maximalen TTL-Wert veraltet sind.](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) Nach Ablauf dieser Dauer ist das Objekt nicht mehr im Edge-Cache verfügbar.
## Die HTTP-Statuscodes 4xx und 5xx, die zwischengespeichert werden CloudFront
CloudFront speichert die von Ihrem Ursprung zurückgegebenen HTTP 4xx- und 5xx-Statuscodes im Cache, abhängig vom jeweiligen Statuscode, der zurückgegeben wird, und davon, ob Ihr Ursprung in der Antwort bestimmte Header zurückgibt.
CloudFront speichert die folgenden HTTP-Statuscodes 4xx und 5xx, die von Ihrem Ursprung zurückgegeben wurden. Wenn Sie eine benutzerdefinierte Fehlerseite für einen HTTP-Statuscode konfiguriert haben, wird die benutzerdefinierte Fehlerseite CloudFront zwischengespeichert.
**Anmerkung**
Wenn Sie die Richtlinie für [CachingDisabled](using-managed-cache-policies.md#managed-cache-policy-caching-disabled) verwaltete Caches verwenden, CloudFront werden diese Statuscodes oder benutzerdefinierten Fehlerseiten nicht zwischengespeichert.
| | |
| --- |--- |
| 404 | Not Found |
| 414 | Anfrage-URI zu lang |
| 500 | Internal Server Error |
| 501 | Nicht implementiert |
| 502 | Bad Gateway |
| 503 | Service nicht verfügbar |
| 504 | Gateway-Timeout |
### HTTP 4xx-Statuscodes, die basierend auf CloudFront Headern zwischengespeichert werden `Cache-Control`
CloudFront speichert nur die folgenden HTTP 4xx-Statuscodes, die von Ihrem Ursprung zurückgegeben werden, zwischenspeichert, wenn Ihr Ursprung einen OR-Header zurückgibt. `Cache-Control max-age` `Cache-Control s-maxage` Wenn du eine benutzerdefinierte Fehlerseite für einen dieser HTTP-Statuscodes konfiguriert hast und dein Origin einen der Cache-Control-Header zurückgibt, wird die benutzerdefinierte Fehlerseite CloudFront zwischengespeichert.
| | |
| --- |--- |
| 400 | Inkorrekte Anfrage |
| 403 | Forbidden |
| 405 | Method Not Allowed |
| 412¹ | Vorbedingung fehlgeschlagen |
| 415¹ | Unsupported Media Type (Nicht unterstützter Medientyp) |
¹ unterstützt CloudFront nicht die Erstellung benutzerdefinierter Fehlerseiten für diese HTTP-Statuscodes.
# Erstellen von benutzerdefinierten Fehlerantworten
Wenn ein Objekt, über das Sie bereitstellen, aus irgendeinem Grund nicht verfügbar CloudFront ist, gibt Ihr Webserver in der Regel einen entsprechenden HTTP-Statuscode zurück, CloudFront um darauf hinzuweisen. Wenn ein Betrachter beispielsweise eine ungültige URL anfordert, gibt Ihr Webserver einen HTTP-Statuscode 404 (Not Found) CloudFront zurück und gibt diesen Statuscode dann an den Betrachter zurück. CloudFront Anstatt diese Standardfehlerantwort zu verwenden, können Sie eine benutzerdefinierte Antwort erstellen, die zum Viewer CloudFront zurückkehrt.
Wenn Sie die Rückgabe einer benutzerdefinierten Fehlerseite für einen HTTP-Statuscode konfigurieren CloudFront , die benutzerdefinierte Fehlerseite jedoch nicht verfügbar ist, wird der Statuscode, den Sie von der Quelle CloudFront erhalten haben und die benutzerdefinierten Fehlerseiten enthalten, an den Betrachter CloudFront zurückgegeben. Nehmen wir zum Beispiel an, Ihr benutzerdefinierter Ursprung gibt einen Statuscode 500 zurück und Sie haben konfiguriert CloudFront , dass eine benutzerdefinierte Fehlerseite für einen 500-Statuscode aus einem Amazon S3-Bucket abgerufen wird. Jemand hat jedoch versehentlich die benutzerdefinierte Fehlerseite aus Ihrem Amazon S3 S3-Bucket gelöscht. CloudFront gibt einen HTTP-404-Statuscode (Nicht gefunden) an den Betrachter zurück, der das Objekt angefordert hat.
Wenn eine benutzerdefinierte Fehlerseite an einen Betrachter CloudFront zurückgegeben wird, zahlen Sie die CloudFront Standardgebühren für die benutzerdefinierte Fehlerseite, nicht die Gebühren für das angeforderte Objekt. Weitere Informationen zu CloudFront Gebühren finden Sie unter [ CloudFrontAmazon-Preise](https://aws.amazon.com/cloudfront/pricing/).
**Topics**
+ [Konfigurieren des Fehlerantwortverhaltens](custom-error-pages-procedure.md)
+ [Erstellen einer benutzerdefinierten Fehlerseite für bestimmte HTTP-Statuscodes](creating-custom-error-pages.md)
+ [Speichern von Objekten und benutzerdefinierten Fehlerseiten an anderen Speicherorten](custom-error-pages-different-locations.md)
+ [Ändern Sie die Antwortcodes, die zurückgegeben wurden von CloudFront](custom-error-pages-response-code.md)
+ [Steuern Sie, wie lange Fehler CloudFront zwischengespeichert werden](custom-error-pages-expiration.md)
# Konfigurieren des Fehlerantwortverhaltens
Sie haben mehrere Optionen, um zu verwalten, wie CloudFront auf einen Fehler reagiert wird. Um benutzerdefinierte Fehlerantworten zu konfigurieren, können Sie die CloudFront Konsole, die CloudFront API oder verwenden CloudFormation. Unabhängig davon, wie Sie die Konfiguration aktualisieren, sollten Sie die folgenden Tipps und Empfehlungen beachten:
+ Speichern Sie Ihre benutzerdefinierten Fehlerseiten an einem Ort, auf den zugegriffen werden kann CloudFront. Wir empfehlen Ihnen, sie in einem Amazon-S3-Bucket zu speichern und [sie nicht am selben Ort wie den Rest der Inhalte Ihrer Website oder Anwendung zu speichern](custom-error-pages-different-locations.md). Wenn Sie die benutzerdefinierten Fehlerseiten auf demselben Ursprung wie Ihre Website oder Anwendung speichern und der Ursprung beginnt, 5xx-Fehler zurückzugeben, CloudFront können Sie die benutzerdefinierten Fehlerseiten nicht abrufen, da der Ursprungsserver nicht verfügbar ist. Weitere Informationen finden Sie unter [Speichern von Objekten und benutzerdefinierten Fehlerseiten an anderen Speicherorten](custom-error-pages-different-locations.md).
+ Stellen Sie sicher, dass dieser Benutzer berechtigt CloudFront ist, Ihre benutzerdefinierten Fehlerseiten abzurufen. Wenn die benutzerdefinierten Fehlerseiten in Amazon S3 gespeichert sind, müssen die Seiten öffentlich zugänglich sein oder Sie müssen eine CloudFront [Origin Access Control (OAC)](private-content-restricting-access-to-s3.md) konfigurieren. Wenn die benutzerdefinierten Fehlerseiten in einem benutzerdefinierten Ursprung gespeichert sind, müssen die Seiten öffentlich zugänglich sein.
+ (Optional) Konfigurieren Sie Ihren Ursprung so, dass ein `Cache-Control`- oder `Expires`-Header zusammen mit den benutzerdefinierten Fehlerseiten hinzugefügt wird, wenn Sie möchten. Sie können auch die Einstellung **Minimum TTL für Error Caching** verwenden, um zu steuern, wie lange die benutzerdefinierten Fehlerseiten CloudFront zwischengespeichert werden. Weitere Informationen finden Sie unter [Steuern Sie, wie lange Fehler CloudFront zwischengespeichert werden](custom-error-pages-expiration.md).
## Konfigurieren benutzerdefinierter Fehlerantworten
Um benutzerdefinierte Fehlerantworten in der CloudFront Konsole zu konfigurieren, benötigen Sie eine Distribution. CloudFront In der Konsole stehen die Konfigurationseinstellungen für benutzerdefinierte Fehlerantworten nur für vorhandene Verteilungen zur Verfügung. Informationen zum Erstellen einer Verteilung finden Sie unter [Beginnen Sie mit einer CloudFront Standarddistribution](GettingStarted.SimpleDistribution.md).
------
#### [ Console ]
**Konfigurieren benutzerdefinierter Fehlerantworten (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Seite **Verteilungen** in der CloudFront Konsole unter[https://console.aws.amazon.com/cloudfront/v4/home#distributions](https://console.aws.amazon.com/cloudfront/v4/home#distributions).
1. Wählen Sie in der Liste der Verteilungen die zu aktualisierende Verteilung aus.
1. Wählen Sie die Registerkarte **Fehlerseiten** und wählen Sie dann **Benutzerdefinierte Fehlerantwort erstellen**.
1. Geben Sie die entsprechenden Werte ein. Weitere Informationen finden Sie unter [Benutzerdefinierte Fehlerseiten und Zwischenspeicherung von Fehlern](DownloadDistValuesErrorPages.md).
1. Nachdem Sie die gewünschten Werte eingegeben haben, wählen Sie **Erstellen**.
------
#### [ CloudFront API or CloudFormation ]
Um benutzerdefinierte Fehlerantworten mit der CloudFront API oder zu konfigurieren CloudFormation, verwenden Sie den `CustomErrorResponse` Typ in einer Distribution. Weitere Informationen finden Sie hier:
+ [AWS::CloudFront::Distribution CustomErrorResponse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-customerrorresponse.html) im *AWS CloudFormation -Benutzerhandbuch*
+ [CustomErrorResponse](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CustomErrorResponse.html)in der *Amazon CloudFront API-Referenz*
------
# Erstellen einer benutzerdefinierten Fehlerseite für bestimmte HTTP-Statuscodes
Wenn Sie statt der Standardmeldung lieber eine benutzerdefinierte Fehlermeldung anzeigen möchten, z. B. eine Seite, die dieselbe Formatierung wie der Rest Ihrer Website verwendet, können Sie ein Objekt (z. B. eine HTML-Datei), das Ihre benutzerdefinierte Fehlermeldung enthält, an den Viewer CloudFront zurückgeben lassen.
Um die Datei, die Sie zurückgeben möchten, und die Fehler, für die die Datei zurückgegeben werden soll, anzugeben, aktualisieren Sie Ihre CloudFront Distribution, sodass diese Werte angegeben werden. Weitere Informationen finden Sie unter [Konfigurieren des Fehlerantwortverhaltens](custom-error-pages-procedure.md).
Zum Beispiel ist das Folgende eine benutzerdefinierte Fehlerseite:
![\[Screenshot einer benutzerdefinierten AWS 404-Beispielseite.\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/images/custom-error-page-aws-404-example.png)
Sie können ein anderes Objekt für jeden unterstützten HTTP-Statuscode festlegen oder Sie können dasselbe Objekt für alle unterstützten Statuscodes verwenden. Es ist möglich, benutzerdefinierte Fehlerseiten für einige Statuscodes festzulegen und für andere nicht.
Die Objekte, über die Sie bereitstellen, CloudFront können aus verschiedenen Gründen nicht verfügbar sein. Diese gliedern sich in zwei große Kategorien:
+ *Client-Fehler* weisen auf ein Problem mit der Anfrage hin. Beispielsweise ist ein Objekt mit dem angegebenen Namen nicht verfügbar oder der Benutzer verfügt nicht über die erforderlichen Berechtigungen, um ein Objekt in Ihrem Amazon S3-Bucket abzurufen. Wenn ein Client-Fehler auftritt, gibt der Ursprung einen HTTP-Statuscode im Bereich 4xx bis CloudFront zurück.
+ *Server-Fehler* weisen auf ein Problem mit dem Ursprungs-Server hin. Beispielsweise ist der HTTP-Server ausgelastet oder nicht verfügbar. Wenn ein Serverfehler auftritt, gibt Ihr Ursprungsserver entweder einen HTTP-Statuscode im Bereich 5xx zurück oder CloudFront er erhält für einen bestimmten Zeitraum keine Antwort von Ihrem Ursprungsserver und nimmt den Statuscode 504 an (Gateway Timeout). CloudFront
Zu den HTTP-Statuscodes, für die eine benutzerdefinierte Fehlerseite zurückgegeben werden CloudFront kann, gehören die folgenden:
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
**Hinweise**
Wenn CloudFront erkannt wird, dass die Anfrage möglicherweise unsicher ist, wird anstelle einer benutzerdefinierten Fehlerseite ein 400-Fehler (Bad Request) CloudFront zurückgegeben.
Sie können eine benutzerdefinierte Fehlerseite für den HTTP-Statuscode 416 (Requested Range Not Satisfiable) erstellen und Sie können den HTTP-Statuscode ändern, der den Zuschauern CloudFront zurückgegeben wird, wenn Ihr Absender den Statuscode 416 an zurückgibt. CloudFront Weitere Informationen finden Sie unter [Ändern Sie die Antwortcodes, die zurückgegeben wurden von CloudFront](custom-error-pages-response-code.md). Status-Code 416-Antworten werden jedoch CloudFront nicht zwischengespeichert, sodass dieser auch dann nicht verwendet wird, wenn Sie für den Statuscode 416 einen Wert für **Error Caching Minimum TTL** angeben. CloudFront
In einigen Fällen CloudFront gibt es keine benutzerdefinierte Fehlerseite für den HTTP-Statuscode 503 zurück, selbst wenn Sie dies konfigurieren CloudFront . Wenn der CloudFront Fehlercode `Capacity Exceeded` oder ist`Limit Exceeded`, wird ein 503-Statuscode an den Viewer CloudFront zurückgegeben, ohne Ihre benutzerdefinierte Fehlerseite zu verwenden.
Wenn Sie eine benutzerdefinierte Fehlerseite erstellt haben, CloudFront wird `Connection: keep-alive` für die folgenden Antwortcodes `Connection: close` oder zurückgegeben:
CloudFront gibt `Connection: close` für Statuscodes zurück: 400, 405, 414, 416, 500, 501
CloudFront gibt `Connection: keep-alive` für Statuscodes zurück: 403, 404, 502, 503, 504
Eine ausführliche Erläuterung, wie CloudFront mit Fehlerantworten aus Ihrem System umgegangen wird, finden Sie unter[Wie CloudFront werden die HTTP-Statuscodes 4xx und 5xx von Ihrem Ursprung verarbeitet](HTTPStatusCodes.md).
# Speichern von Objekten und benutzerdefinierten Fehlerseiten an anderen Speicherorten
Wenn Sie Ihre Objekte und Ihre benutzerdefinierten Fehlerseiten an verschiedenen Orten speichern möchten, muss Ihre Verteilung ein Cache-Verhalten mit den folgenden Eigenschaften enthalten:
+ Der Wert von **Path Pattern** stimmt mit dem Pfad zu Ihren benutzerdefinierten Fehlermeldungen überein. Angenommen, Sie haben benutzerdefinierte Fehlerseiten für 4xx-Fehler in einem Amazon S3-Bucket in einem Verzeichnis mit dem Namen gespeicher `/4xx-errors`. Ihre Verteilung muss ein Cache-Verhalten beinhalten, für welches das Pfadmuster Anfragen für Ihre benutzerdefinierten Fehlerseiten an diesen Ort weiterleitet, z. B, `/4xx-errors/*`.
+ Der Wert von **Origin** legt den Wert von **Origin ID** für den Ursprung fest, der Ihre benutzerdefinierten Fehlerseiten enthält.
Weitere Informationen finden Sie unter [Einstellungen für das Cache-Verhalten](DownloadDistValuesCacheBehavior.md).
# Ändern Sie die Antwortcodes, die zurückgegeben wurden von CloudFront
Sie können so konfigurieren CloudFront , dass dem Betrachter ein anderer HTTP-Statuscode zurückgegeben wird als der, den CloudFront er vom Absender erhalten hat. Wenn Ihr Absender beispielsweise den Statuscode 500 an zurückgibtCloudFront, CloudFront möchten Sie möglicherweise eine benutzerdefinierte Fehlerseite und den Statuscode 200 (OK) an den Betrachter zurückgeben. Es gibt eine Vielzahl von Gründen, warum Sie dem Betrachter möglicherweise einen Statuscode zurückgeben CloudFront möchten, der sich von dem unterscheidet, zu dem Ihr Ursprung zurückgekehrt istCloudFront:
+ Einige Internetgeräte (beispielsweise einige Firewalls und Unternehmens-Proxys) fangen HTTP 4xx- und 5xx-Statuscodes ab und verhindern, dass die Antwort an den Betrachter zurückgegeben wird. Wenn Sie in diesem Szenario `200` ersetzen, wird die Antwort nicht abgefangen.
+ Wenn Sie nicht zwischen verschiedenen Client- oder Serverfehlern unterscheiden möchten, können Sie `400` oder `500` als den Wert angeben, der für alle 4xx- oder 5xx-Statuscodes CloudFront zurückgegeben wird.
+ Möglicherweise möchten Sie einen `200`-Statuscode (OK) und eine statische Website zurückgeben, sodass Ihre Kunden nicht wissen, dass die Website nicht verfügbar ist.
Wenn Sie [CloudFront Standardprotokolle](AccessLogs.md) aktivieren und so konfigurierenCloudFront , dass der HTTP-Statuscode in der Antwort geändert wird, enthält der Wert der `sc-status` Spalte in den Protokollen den von Ihnen angegebenen Statuscode. Der Wert der `x-edge-result-type`-Spalte wird jedoch nicht beeinflusst. Sie enthält den Ergebnistyp der Antwort vom Ursprung. Nehmen wir zum Beispiel an, Sie konfigurieren CloudFront , dass der Statuscode von `200` an den Betrachter zurückgegeben wird, wenn der Ursprung `404` (Not Found) zu zurückkehrt CloudFront. Wenn der Ursprung auf eine Anfrage mit dem Statuscode `404` antwortet, ist der Wert in der Spalte `sc-status` im Protokoll `200`, der Wert in der Spalte `x-edge-result-type` jedoch `Error`.
Sie können so konfigurieren CloudFront , dass jeder der folgenden HTTP-Statuscodes zusammen mit einer benutzerdefinierten Fehlerseite zurückgegeben wird:
+ 200
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
# Steuern Sie, wie lange Fehler CloudFront zwischengespeichert werden
CloudFront speichert Fehlerantworten für eine Standarddauer von 10 Sekunden im Cache. CloudFront sendet dann die nächste Anfrage für das Objekt an Ihre Quelle, um zu überprüfen, ob das Problem, das den Fehler verursacht hat, behoben wurde und das angeforderte Objekt verfügbar ist.
Sie können für jeden 4xx- und 5xx-Statuscode, der zwischengespeichert wird, die Dauer des **Fehler-Cachings — die Mindest-TTL für das Fehler-Caching** angeben. CloudFront (Weitere Informationen finden Sie unter [Die HTTP-Statuscodes 4xx und 5xx, die zwischengespeichert werden CloudFront](HTTPStatusCodes.md#HTTPStatusCodes-cached-errors).) Wenn Sie eine Dauer angeben, beachten Sie Folgendes:
+ Wenn Sie eine kurze Dauer für das Zwischenspeichern von Fehlern angeben, werden mehr Anfragen an Ihren Ursprung weitergeleitet, CloudFront als wenn Sie eine längere Dauer angeben. Bei 5xx-Fehlern verschlimmert dies möglicherweise das Problem, das ursprünglich dazu geführt hat, dass Ihr Ursprung einen Fehler zurückgibt.
+ Wenn Ihr Absender einen Fehler für ein Objekt zurückgibt, CloudFront beantwortet er Anfragen für das Objekt entweder mit der Fehlerantwort oder mit Ihrer benutzerdefinierten Fehlerseite, bis die Dauer der Fehlerzwischenspeicherung abgelaufen ist. Wenn Sie eine lange Dauer für das Zwischenspeichern von Fehlern angeben, reagiert das CloudFront Objekt möglicherweise noch lange auf Anfragen mit einer Fehlerantwort oder Ihrer benutzerdefinierten Fehlerseite, nachdem das Objekt wieder verfügbar ist.
**Anmerkung**
Sie können eine benutzerdefinierte Fehlerseite für HTTP-Statuscode 416 (Requested Range Not Satisfiable) erstellen und Sie können den HTTP-Statuscode ändern, den CloudFront an Betrachter zurückgibt, wenn Ihr Ursprung einen Statuscode 416 an CloudFront zurückgibt. (Weitere Informationen finden Sie unter [Ändern Sie die Antwortcodes, die zurückgegeben wurden von CloudFront](custom-error-pages-response-code.md).) Status-Code 416-Antworten werden jedoch CloudFront nicht zwischengespeichert. Selbst wenn Sie einen Wert für **Error Caching Minimum TTL** für den Statuscode 416 angeben, wird dieser Wert nicht verwendet. CloudFront
Wenn Sie steuern möchten, wie lange Fehler für einzelne Objekte CloudFront zwischengespeichert werden, können Sie Ihren Ursprungsserver so konfigurieren, dass er der Fehlerantwort für dieses Objekt den entsprechenden Header hinzufügt.
Wenn der Ursprung eine `Cache-Control: s-maxage` OR-Direktive `Cache-Control: max-age` oder einen `Expires` Header hinzufügt, werden Fehlerantworten CloudFront zwischengespeichert, je nachdem, welcher Wert im Header oder der Mindest-TTL für **Error Caching gilt**.
**Anmerkung**
Beachten Sie, dass die Werte für `Cache-Control: max-age` und `Cache-Control: s-maxage` nicht größer als der Wert für **Maximum TTL** sein können, der für das Cache-Verhalten festgelegt wurde, für das die Fehlerseite abgerufen wird.
Wenn der Ursprung eine `Cache-Control: private` Direktive `Cache-Control: no-store``Cache-Control: no-cache`, oder für die Fehlercodes 404, 410, 414 oder 501 hinzufügt, wird die CloudFront Fehlerantwort nicht zwischengespeichert. CloudFront Ignoriert bei allen anderen Fehlercodes die `private` Direktiven `no-store``no-cache`, und und speichert die Fehlerantwort für den Wert **Error Caching** Minimum TTL zwischen.
**Wenn der Ursprung weitere `Cache-Control` Direktiven hinzufügt oder keine Header hinzufügt, werden die Fehlerantworten für den Wert von Error CloudFront Caching Minimum TTL zwischengespeichert.**
Wenn die Ablaufzeit für einen 4xx- oder 5xx-Statuscode für ein Objekt länger ist, als Sie warten möchten, und das Objekt wieder verfügbar ist, können Sie den zwischengespeicherten Fehlercode mit der URL des angefragten Objekts aufheben. Wenn Ihr Ursprung eine Fehlermeldung für mehrere Objekte zurückgibt, müssen Sie die Gültigkeit aller Objekte einzeln aufheben. Weitere Informationen zur Aufhebung der Gültigkeit von Objekten finden Sie unter [Aufheben der Gültigkeit von Dateien zum Entfernen von Inhalten](Invalidation.md).
Wenn Sie das Caching für einen S3-Bucket-Ursprung aktiviert haben und Sie in Ihrer CloudFront Distribution einen Fehler beim Zwischenspeichern einer Mindest-TTL von 0 Sekunden konfigurieren, wird immer noch ein Fehler beim Zwischenspeichern einer Mindest-TTL von 1 Sekunde für Fehler mit S3-Ursprung angezeigt. CloudFront tut dies, um Ihren Origin vor S-Angriffen zu schützen. DDo Dies gilt nicht für andere Arten von Ursprüngen.