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 Absender weiter

Erfahren Sie, wie Zuschaueranfragen CloudFront verarbeitet und die Anfragen an Ihren benutzerdefinierten Ursprung weiterleitet.

Authentifizierung

Wenn Sie den Authorization Header an Ihren Ursprung weiterleiten, können Sie Ihren Ursprungsserver so konfigurieren, dass er für die folgenden Arten von Anfragen eine Client-Authentifizierung anfordert:

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 verwendenHTTPS, um Anfragen an Ihren Ursprungsserver weiterzuleiten. Weitere Informationen finden Sie unter Verwenden Sie HTTPS mit CloudFront.

Dauer und Mindestdauer des Zwischenspeichers 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:

Weitere Informationen finden Sie unter Verwalten Sie, wie lange Inhalte im Cache verbleiben (Ablauf).

Client-IP-Adressen

Wenn ein Viewer eine Anfrage an sendet CloudFront und keinen X-Forwarded-For 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. Wenn CloudFront er beispielsweise die IP-Adresse 192.0.2.2 von der TCP Verbindung erhält, leitet er den folgenden Header an den Ursprung weiter:

X-Forwarded-For: 192.0.2.2

Wenn ein Betrachter eine Anfrage an sendet CloudFront und einen X-Forwarded-For Anforderungsheader einfügt, CloudFront ruft er die IP-Adresse des Betrachters 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. Wenn die Viewer-Anfrage beispielsweise die IP-Adresse 192.0.2.2 aus der TCP Verbindung enthält X-Forwarded-For: 192.0.2.4,192.0.2.3 und diese 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), 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, an die sie weitergeleitet wird, ELB 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

Clientseitige Authentifizierung SSL

CloudFront unterstützt keine Client-Authentifizierung mit SSL clientseitigen Zertifikaten. Wenn ein Ursprung ein clientseitiges Zertifikat anfordert, CloudFront wird die Anfrage gelöscht.

Komprimierung

Weitere Informationen finden Sie unter Komprimierte Dateien bereitstellen.

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:

Der Ursprung bestimmt anhand dieser Informationen, ob das Objekt aktualisiert wurde und ob daher das gesamte Objekt CloudFront oder nur der Statuscode HTTP 304 (nicht geändert) zurückgegeben werden soll.

Cookies

Sie können so konfigurieren CloudFront , dass Cookies an Ihren Ursprung weitergeleitet werden. Weitere Informationen finden Sie unter Auf Cookies basierender Inhalt zwischenspeichern.

Quellenübergreifende gemeinsame Nutzung von Ressourcen () 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 Inhalt auf der Grundlage von Anforderungsheadern zwischenspeichern.

Verschlüsselung

Sie können festlegen, dass Zuschauer Anfragen HTTPS an Ihren benutzerdefinierten Absender senden CloudFront und Anfragen CloudFront an Ihren benutzerdefinierten Absender weiterleiten müssen, indem Sie das Protokoll verwenden, das vom Betrachter verwendet wird. Weitere Informationen finden Sie in den folgenden Verteilungseinstellungen:

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

Wenn der Ursprung ein Amazon S3 S3-Bucket ist, wird CloudFront immer TLSv1 .2 verwendet.

Weitere Hinweise zur Verwendung von HTTPS with CloudFront finden Sie unterVerwenden Sie HTTPS mit CloudFront. Eine Liste der Chiffren, die die HTTPS Kommunikation zwischen Zuschauern und zwischen CloudFront und Ihrer Herkunft CloudFront unterstützen CloudFront, finden Sie unter. Unterstützte Protokolle und Chiffren zwischen Zuschauern und CloudFront

GETAnfragen, die einen Hauptteil enthalten

Wenn eine GET Viewer-Anfrage einen Hauptteil enthält, wird dem Betrachter der HTTP Statuscode 403 (Forbidden) CloudFront zurückgegeben.

HTTPMethoden

Wenn Sie so konfigurieren CloudFront , dass alle unterstützten HTTP Methoden verarbeitet werden, CloudFront akzeptiert es die folgenden Anfragen von Zuschauern und leitet sie an Ihren benutzerdefinierten Ursprung weiter:

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 keine Antworten auf Anfragen, die die anderen Methoden verwenden.

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

HTTPAnforderungsheader und CloudFront Verhalten (benutzerdefiniert und Amazon S3 S3-Ursprünge)

In der folgenden Tabelle sind HTTP Anforderungsheader aufgeführt, die Sie sowohl an benutzerdefinierte als auch an Amazon S3 S3-Ursprünge weiterleiten können (mit den angegebenen Ausnahmen). Für jeden Header umfasst die Tabelle Informationen über Folgendes:

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

HTTPVersion

CloudFront leitet Anfragen mit /1.1 an Ihren benutzerdefinierten HTTP 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 a URL aus der Anfrage. Die maximale Länge URL beträgt 8192 Byte.

Wenn eine Anfrage oder eine diese Höchstwerte URL ü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.

OCSPHeften

Wenn ein Betrachter eine HTTPS Anfrage für ein Objekt einreicht, muss entweder der Betrachter CloudFront oder der Betrachter bei der Zertifizierungsstelle (CA) bestätigen, dass das SSL Zertifikat für die Domain nicht gesperrt wurde. OCSPStapling beschleunigt die Zertifikatsvalidierung CloudFront , da das Zertifikat validiert und die Antwort von der Zertifizierungsstelle zwischengespeichert werden kann, sodass der Client das Zertifikat nicht direkt bei der CA validieren muss.

Die Leistungsverbesserung durch OCSP Heften ist ausgeprägter, wenn CloudFront zahlreiche HTTPS Anfragen nach Objekten in derselben Domäne eingehen. Jeder Server an einem CloudFront Edge-Standort muss eine separate Überprüfungsanforderung einreichen. Wenn viele HTTPS Anfragen für dieselbe Domäne 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 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. Die Aufrechterhaltung einer dauerhaften Verbindung spart Zeit, die erforderlich ist, um die TCP Verbindung wiederherzustellen und einen weiteren TLS Handshake für nachfolgende Anfragen durchzuführen.

Weitere Informationen, einschließlich solcher zur Konfiguration der Dauer ständiger Verbindungen, finden Sie unter Keepalive-Timeout (nur benutzerdefinierte Ursprünge) im Abschnitt Referenz zu Verteilungseinstellungen.

Protokolle

CloudFront leitet HTTPS Anfragen HTTP oder Anfragen an den Ursprungsserver weiter, die auf folgenden Grundlagen basieren:

Wenn Sie HTTPOnly oder HTTPSOnly angeben, werden Anfragen mit dem angegebenen Protokoll an den Ursprungsserver CloudFront weitergeleitet, unabhängig vom Protokoll in der Viewer-Anfrage.

Wenn Sie Match Viewer angeben, CloudFront werden Anfragen mithilfe des Protokolls in der Viewer-Anfrage an den Ursprungsserver weitergeleitet. Beachten Sie, dass das Objekt nur einmal CloudFront zwischengespeichert wird, auch wenn Zuschauer Anfragen mit beiden HTTP Protokollen HTTPS stellen.

Hinweise zum Aktualisieren einer Distribution mithilfe der CloudFront Konsole finden Sie unter. Eine Verteilung aktualisieren Informationen zum Aktualisieren einer Distribution mithilfe von finden Sie UpdateDistributionin der CloudFront APIAmazon-Referenz. CloudFront API

Abfragezeichenfolgen

Sie können konfigurieren, ob CloudFront Abfragezeichenfolgenparameter an Ihren Ursprung weitergeleitet werden. Weitere Informationen finden Sie unter Cache-Inhalt auf der Grundlage von Abfragezeichenfolgenparametern.

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 Kontrolliere Timeouts und Versuche bei der Herkunft.

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 Reaktions-Timeout (nur benutzerdefinierte Ursprünge).

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 unterCloudFront und Edge-Funktionsprotokollierung.

CloudFront reduziert nur Anfragen, die sich einen Cache-Schlüssel 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.

Wenn Sie verhindern möchten, dass alle Anfragen kollabiert werden, können Sie die verwaltete Cache-Richtlinie verwendenCachingDisabled, die auch das Zwischenspeichern verhindert. Weitere Informationen finden Sie unter Verwaltete Cache-Richtlinien verwenden.

Wenn Sie verhindern möchten, dass Anfragen für bestimmte Objekte reduziert werden, können Sie das Minimum TTL für das Cache-Verhalten auf 0 setzen und den Ursprung so konfigurieren, dass erCache-Control: private,, Cache-Control: no-storeCache-Control: no-cache, Cache-Control: max-age=0 oder sendet. Cache-Control: s-maxage=0 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.

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 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 CloudFront könnte bei einigen Tablet-Geräten sowohl als auch CloudFront-Is-Mobile-Viewer auf festgelegt CloudFront-Is-Tablet-Viewer werdentrue. Weitere Informationen zur Konfiguration der CloudFront Zwischenspeicherung auf der Grundlage von Anforderungsheadern finden Sie unterInhalt auf der Grundlage von Anforderungsheadern zwischenspeichern.

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.

100 Continue Antworten

Ihr Absender kann nicht mehr als eine 100-Continue-Antwort an CloudFront senden. Nach der ersten 100-Continue-Antwort wird eine HTTP 200-OK-Antwort CloudFront erwartet. Wenn Ihr Absender nach der ersten Antwort 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 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, leitet aber dennoch jede nachfolgende Anfrage für das Objekt an den Ursprung weiter, 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 beschriebenHTTPAntwortheader, die CloudFront entfernen oder ersetzen.

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 Auf Cookies basierender Inhalt zwischenspeichern.

Verbindungen wurden unterbrochen TCP

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 in der Antwort einen Content-Length Header enthalten hat:

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

HTTPAntwortheader, die CloudFront entfernen oder ersetzen

CloudFront entfernt oder aktualisiert die folgenden Header-Felder, bevor die Antwort von Ihrer Quelle an den Betrachter 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 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 angezeigt. Weitere Informationen zum CloudFront Verhalten bei der Konfiguration benutzerdefinierter Fehlerseiten finden Sie unterWie CloudFront werden Fehler verarbeitet, wenn Sie benutzerdefinierte Fehlerseiten konfiguriert haben.

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:

Transfer-Encoding-Header

CloudFront unterstützt nur den chunked Wert des Transfer-Encoding Headers. Wenn Ihr Ursprung CloudFront zurückkehrtTransfer-Encoding: chunked, sendet er das Objekt an den Client zurück, sobald das Objekt am Edge-Standort empfangen wurde, und speichert das Objekt im Chunk-Format für nachfolgende Anfragen im Cache.

Wenn der Betrachter eine Range GET Anfrage stellt und der Ursprung CloudFront zurückkehrtTransfer-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 Verbindungen wurden unterbrochen TCP.