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:

Wie CloudFront verarbeitet und leitet Anfragen an Ihren benutzerdefinierten Ursprung weiter

Erfahre, wie Zuschaueranfragen CloudFront verarbeitet und die Anfragen an deinen benutzerdefinierten Absender weitergeleitet werden.

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:

Für OPTIONS Anfragen kann die Client-Authentifizierung nur konfiguriert werden, wenn Sie die folgenden CloudFront Einstellungen verwenden:

Weitere Informationen finden Sie unter So konfigurieren CloudFront , dass der Header weitergeleitet wird Authorization.

Sie können HTTP oder HTTPS verwenden, um Anforderungen an Ihren Ursprungsserver weiterzuleiten. Weitere Informationen finden Sie unter Verwenden Sie HTTPS mit CloudFront.

Cache-Dauer und Mindest-TTL

Um zu steuern, wie lange Ihre Objekte in einem CloudFront Cache bleiben, bevor CloudFront sie eine weitere Anfrage an Ihren Ursprung weiterleiten, können Sie:

Weitere Informationen finden Sie unter Verwalten der Dauer, die Inhalte im Cache bleiben (Ablauf).

Client-IP-Adressen

Wenn ein Viewer eine Anfrage an einen Anforderungsheader sendet CloudFront und keinen X-Forwarded-For Anforderungsheader enthält, CloudFront ruft er die IP-Adresse des Viewers von 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. 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 Viewer eine Anfrage an einen Request-Header sendet CloudFront und einen X-Forwarded-For Request-Header einschließt, CloudFront ruft er die IP-Adresse des Viewers von der TCP-Verbindung ab, hängt sie an das Ende des X-Forwarded-For Headers an und leitet die Anfrage an den Ursprung weiter. 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 192.0.2.2 von ihr CloudFront 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), Web Application 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 weiterleitet, und wenn die IP-Adresse des CloudFront Edge-Servers 192.0.2.199 lautet, enthält die Anforderung, die Ihre EC2-Instance empfängt, den folgenden Header:

X-Forwarded-For: 192.0.2.2,192.0.2.199

Client-side SSL-Authentifizierung

CloudFront unterstützt die gegenseitige TLS-Authentifizierung (mTLS), bei der sowohl der Client als auch der Server sich 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 Ursprüngen, die clientseitige Zertifikate anfordern, wenn 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

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.

Bedingte Anforderungen

Wenn CloudFront er von einem Edge-Cache eine Anforderung für ein Objekt erhält, das abgelaufen ist, leitet er die Anforderung 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 enthielt die Antwort einen Wert CloudFront, einen ETag Wert oder beide Werte, als der Ursprung das Objekt das letzte Mal gesendet hat. LastModified Fügt in der neuen Anfrage CloudFront , die an den Ursprung weitergeleitet wird, eines oder beide der folgenden Elemente CloudFront hinzu:

Der Ursprung verwendet diese Informationen, um zu ermitteln, ob das Objekt aktualisiert wurde und ob daher das gesamte Objekt an einen HTTP 304-Statuscode (nicht geändert) zurückgegeben werden soll CloudFront oder nur an einen HTTP 304-Statuscode zurückgegeben werden soll.

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.

Cross-origin gemeinsame Nutzung von Ressourcen (CORS)

Wenn Sie die Einstellungen CloudFront für die ursprungsübergreifende gemeinsame Nutzung von Ressourcen berücksichtigen möchten, konfigurieren Sie, CloudFront dass der Origin Header an Ihren Ursprung weitergeleitet wird. Weitere Informationen finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Anforderungsheadern.

Verschlüsselung

Sie können festlegen, 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 Viewer verwendet wird. Weitere Informationen finden Sie in den folgenden Verteilungseinstellungen:

CloudFront leitet HTTPS-Anfragen mithilfe der Protokolle SSLv3, TLSv1.0 TLSv1.1, TLSv1.2 und an den Ursprungsserver weiter. TLSv1.3 Für benutzerdefinierte Ursprünge können Sie die SSL-Protokolle auswählen, die Sie für die Kommunikation mit CloudFront Ihrem Absender verwenden möchten:

Wenn der Ursprung ein Amazon S3-Bucket ist, CloudFront wird standardmäßig verwendet TLSv1.3.

Weitere Informationen zur Verwendung von HTTPS mit CloudFront finden Sie unterVerwenden Sie HTTPS mit CloudFront. Eine Liste der Chiffren, die die HTTPS-Kommunikation zwischen Zuschauern und sowie zwischen CloudFront und Ihrem Absender CloudFront unterstützen CloudFront, finden Sie unter. Unterstützte Protokolle und Chiffren zwischen Zuschauern und CloudFront

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 die Konfiguration so konfigurieren CloudFront , dass alle unterstützten HTTP-Methoden verarbeitet werden, CloudFront akzeptiert es die folgenden Anfragen von Viewern und leitet sie an Ihren benutzerdefinierten Ursprung weiter:

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.

Informationen zur Konfiguration Ihres benutzerdefinierten Ursprungsservers für die Verarbeitung dieser Methoden finden Sie in der Dokumentation zu Ihrem Ursprungsserver.

Header und CloudFront Verhalten von HTTP-Anfragen (benutzerdefiniert und Amazon 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:

Weitere Informationen zum Zwischenspeichern auf Basis von Header-Werten finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Anforderungsheadern.

HTTP-Version

CloudFront leitet Anfragen an Ihren benutzerdefinierten Ursprung weiter mit HTTP/1.1.

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 32.768 Byte.

CloudFront erstellt eine URL aus der Anfrage. Die maximale Länge dieser URL beträgt 8 192 Byte.

Wenn eine URL die maximale Länge überschreitet, wird der HTTP-Statuscode 414 (URI Too Long) an den Viewer CloudFront zurückgegeben. Wenn eine Anforderung die maximale Länge überschreitet, weil die Header-Größe überschritten wird, wird der HTTP-Statuscode 494 an den Viewer CloudFront zurückgegeben. In beiden Fällen CloudFront wird dann die TCP-Verbindung zum Viewer beendet.

OCSP-Stapling

Wenn ein Betrachter eine HTTPS-Anfrage für ein Objekt sendet, muss entweder CloudFront oder der Betrachter bei der Zertifizierungsstelle (CA) bestätigen, dass das SSL-Zertifikat für die Domain nicht gesperrt wurde. OCSP-Stapling beschleunigt die Zertifikatsvalidierung, da CloudFront das Zertifikat validiert und die Antwort 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 Validierungsanforderung 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 empfängt, ist es wahrscheinlicher, dass neue Anfragen an einen Server weitergeleitet werden, der das Zertifikat noch nicht von 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 Validierungsanforderung 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 er eine Antwort von Ihrem Absender erhält, versucht er, die Verbindung für einige Sekunden aufrechtzuerhalten, falls in diesem Zeitraum eine weitere Anfrage eintrifft. 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) im Abschnitt Referenz für alle Distributionseinstellungen.

Protokolle

CloudFront leitet HTTP- oder HTTPS-Anfragen auf der Grundlage der folgenden Kriterien an den Ursprungsserver weiter:

Wenn Sie „Nur HTTP“ oder „Nur HTTPS“ angeben, CloudFront leitet Anfragen mithilfe des angegebenen Protokolls an den Ursprungsserver weiter, unabhängig vom Protokoll in der Viewer-Anfrage.

Wenn Sie Match Viewer angeben, CloudFront leitet es Anfragen mithilfe des Protokolls in der Viewer-Anfrage an den Originalserver weiter. Beachten Sie, dass CloudFront das Objekt nur einmal zwischenspeichert, auch wenn Betrachter ihre Anfragen sowohl über HTTP als auch über HTTPS übertragen.

Hinweise zum Aktualisieren einer Distribution mithilfe der CloudFront Konsole finden Sie unter. Eine Verteilung aktualisieren Informationen zur Aktualisierung einer Distribution mithilfe der CloudFront API finden Sie UpdateDistribution in der CloudFront Amazon-API-Referenz.

Abfragezeichenfolgen

Sie können konfigurieren, ob Abfragezeichenfolgenparameter an Ihren Ursprung CloudFront weitergeleitet werden sollen. Weitere Informationen finden Sie unter Zwischenspeichern von Inhalten auf der Grundlage von Abfragezeichenfolgeparametern.

Timeout der Ursprungsverbindung und Verbindungsversuche zum Ursprung

Das Timeout für die Ursprungsverbindung gibt an, wie viele Sekunden CloudFront gewartet werden, wenn versucht wird, eine Verbindung zum Ursprung herzustellen.

Die Anzahl der Versuche, eine Verbindung zum Ursprung herzustellen, gibt an, wie oft CloudFront versucht wurde, 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 von jeweils 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.

Ursprungs-Reaktions-Timeout

Das Ursprungs-Reaktions-Timeout, das auch als Ursprungs-Lese-Timeout oder Ursprungs-Anforderungs-Timeout bezeichnet wird, gilt für Folgendes:

CloudFront Das Verhalten hängt von der HTTP-Methode der Viewer-Anfrage ab:

Weitere Informationen, einschließlich Informationen zum Konfigurieren des Reaktions-Timeouts für den Ursprungs-Server, finden Sie unter Antwort-Timeout.

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 jedoch gleichzeitig Anfragen für dasselbe Objekt eingehen — das heißt, wenn zusätzliche Anfragen für dasselbe Objekt (mit demselben Cacheschlüssel) an der Edge-Position 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 verringern. CloudFront sendet die Antwort von der ursprünglichen Anfrage auf alle Anfragen, die es während der Pause erhalten hat. Dies wird als Request Collapsing (Zusammenfassung von Anfragen) bezeichnet. In CloudFront Protokollen wird die erste Anfrage Miss im x-edge-result-type Feld als a identifiziert, und die reduzierten Anfragen werden als a identifiziert. Hit Weitere Hinweise zu CloudFront Protokollen finden Sie unterCloudFront und Edge-Funktionsprotokollierung.

CloudFront blendet nur Anfragen aus, die einen Cacheschlüssel gemeinsam verwenden. Wenn die zusätzlichen Anfragen nicht denselben Cacheschlüssel verwenden, weil Sie beispielsweise so konfiguriert CloudFront haben, dass das Zwischenspeichern auf der Grundlage von Anforderungsheadern, Cookies oder Abfragezeichenfolgen erfolgt, CloudFront leitet alle Anfragen mit einem eindeutigen Cacheschlüssel an Ihren Ursprung weiter.

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.

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 die gleichzeitigen Anfragen, die unterbrochen werden, während auf die Antwort auf die CloudFront erste Anfrage gewartet wird.

User-Agent-Header

Wenn Sie je CloudFront nach Gerät, das ein Benutzer zum Anzeigen Ihrer Inhalte verwendet, verschiedene Versionen Ihrer Objekte zwischenspeichern möchten, empfehlen wir Ihnen, die Konfiguration so CloudFront zu konfigurieren, dass eine oder mehrere der folgenden Header an Ihren benutzerdefinierten Ursprung weitergeleitet werden:

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 des Caches CloudFront auf der Grundlage von Anforderungsheadern finden Sie unter. Zwischenspeichern von Inhalten auf der Grundlage von Anforderungsheadern

Sie können so konfigurieren CloudFront , dass Objekte auf der Grundlage von Werten im User-Agent Header zwischengespeichert werden, wir empfehlen dies jedoch nicht. Der User-Agent Header hat viele mögliche Werte, und das Caching 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ügen 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 vom Viewer einen User-Agent Header enthält, CloudFront wird dieser entfernt.

Wie CloudFront verarbeitet Antworten von Ihrem benutzerdefinierten Ursprung

Erfahren Sie, wie Antworten aus Ihrem benutzerdefinierten Ursprung CloudFront verarbeitet werden.

100 Antworten fortsetzen

Ihr Absender kann nicht mehr als eine 100-Continue-Antwort an CloudFront senden. CloudFront Erwartet nach der ersten 100-Continue-Antwort eine HTTP-Antwort mit 200 OK. Wenn Ihr Absender nach der ersten eine weitere 100-Continue-Antwort sendet, CloudFront wird ein Fehler zurückgegeben.

Caching

Abgebrochene Anfragen

Wenn sich ein Objekt nicht im Edge-Cache befindet und ein Viewer eine Sitzung beendet (z. B. einen Browser schließt), nachdem CloudFront er das Objekt von Ihrem Ursprung abgerufen hat, aber bevor er das angeforderte Objekt bereitstellen 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 Cacheverhalten 0 ist, wird das Objekt CloudFront zwischengespeichert, aber dennoch 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 Daher gibt Ihr Ursprung das Objekt als Antwort auf jede Anfrage an zurück. CloudFront

Wenn Ihr Ursprung Vary:* in der Antwort zurückgegeben wird und wenn der Wert von Minimum TTL für das entsprechende Cacheverhalten ein anderer Wert ist, CloudFront verarbeitet der Vary Header wie unter beschriebenHTTP-Antwort-Header, die CloudFront entfernt oder ersetzt werden.

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.

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:

Wir empfehlen, dass Sie Ihren HTTP-Server so konfigurieren, dass er einen Content-Length Header hinzufügt, um zu CloudFront verhindern, dass Teilobjekte zwischengespeichert werden.

HTTP-Antwort-Header, die CloudFront entfernt oder ersetzt werden

CloudFront entfernt oder aktualisiert die folgenden Header-Felder, bevor die Antwort von Ihrem Ursprung an den Viewer weitergeleitet wird:

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.

Ursprung nicht verfügbar

Wenn Ihr Originalserver nicht verfügbar ist und eine Anforderung 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 Anweisung angegebene Zeitraum abgelaufen ist), wird CloudFront entweder die abgelaufene Version des Objekts bereitgestellt oder eine benutzerdefinierte Fehlerseite angezeigt. Weitere Informationen zum CloudFront Verhalten bei der Konfiguration benutzerdefinierter Fehlerseiten finden Sie unterWie CloudFront verarbeitet Fehler, wenn Sie benutzerdefinierte Fehlerseiten konfiguriert haben.

In einigen Fällen wird ein Objekt, das selten angefordert wird, entfernt und ist im Edge-Cache nicht mehr 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 Weiterleitung 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 reagiert mit einer Weiterleitung (z. B.). 302 Moved Temporarily CloudFront speichert die Weiterleitung im Cache und gibt sie an den Viewer zurück. CloudFront folgt der Weiterleitung nicht.

Sie können Ihren Webserver so konfigurieren, dass Anfragen an einen der folgenden Speicherorte umgeleitet werden:

Transfer-Encoding-Header

CloudFront unterstützt nur den chunked Wert des Headers. Transfer-Encoding Wenn Ihr Ursprung CloudFront zurückkehrtTransfer-Encoding: chunked, gibt das Objekt an den Client zurück, sobald es an der Edge-Position empfangen wird, und speichert das Objekt für nachfolgende Anfragen im Chunk-Format.

Wenn der Viewer eine Range GET Anfrage stellt und der Ursprung CloudFront zurückkehrtTransfer-Encoding: chunked, wird das gesamte Objekt an den Viewer zurückgegeben und nicht der angeforderte Bereich.

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.