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 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).