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.
Einschränkungen für alle Edge-Funktionen
Die folgenden Einschränkungen gelten für alle Edge-Funktionen, sowohl für CloudFront Functions als auch für Lambda@Edge.
Themen
AWS-Konto-Eigentümerschaft
Um eine Edge-Funktion mit einer CloudFront-Verteilung zu verknüpfen, müssen die Funktion und die Verteilung Eigentum derselben sein AWS-Konto.
Kombinieren von CloudFront Functions mit Lambda@Edge
Für jedes Cache-Verhalten gelten die folgenden Einschränkungen:
-
Jeder Ereignistyp (Viewer-Anforderung, Ursprungsanforderung, Ursprungsantwort und Viewer-Antwort) kann nur eine Edge-Funktionszuordnung aufweisen.
-
CloudFront Functions und Lambda@Edge können nicht in Viewer-Ereignissen (Viewer-Anforderung und Viewer-Antwort) kombiniert werden.
Alle anderen Kombinationen von Edge-Funktionen sind erlaubt. In der folgenden Tabelle werden die erlaubten Kombinationen erläutert.
|
CloudFront-Funktionen |
|||
|
Viewer-Anforderung |
Viewer-Antwort |
||
|
Lambda@Edge |
Viewer-Anforderung |
Nicht zulässig |
Nicht zulässig |
|
Ursprungsanfrage |
Zulässig |
Zulässig |
|
|
Ursprungsantwort |
Zulässig |
Zulässig |
|
|
Viewer-Antwort |
Nicht zulässig |
Nicht zulässig |
|
HTTP-Statuscodes
CloudFront ruft keine Edge-Funktionen für Viewer-Antwortereignisse auf, wenn der Ursprung den HTTP-Statuscode 400 oder höher zurückgibt.
Lambda@Edge-Funktionen für Ursprungsantwortereignisse werden für alle Ursprungsantworten aufgerufen, auch wenn der Ursprung einen HTTP-Statuscode 400 oder höher zurückgibt. Weitere Informationen finden Sie unter Aktualisieren von HTTP-Antworten in Ursprungsantwortauslösern.
HTTP-Header
Bestimmte HTTP-Header sind nicht zulässig, was bedeutet, dass sie nicht für Edge-Funktionen zugänglich sind und die Funktionen sie nicht hinzufügen können. Andere Header sind schreibgeschützt, was bedeutet, dass die Funktionen sie zwar lesen, aber nicht hinzufügen, ändern oder löschen können.
Unzulässige Header
Die folgenden HTTP-Header sind nicht für Edge-Funktionen verfügbar und die Funktionen können sie nicht hinzufügen. Wenn Ihre Lambda-Funktion einen dieser Header hinzufügt, wird die Anfrage nicht von CloudFront validiert und CloudFront gibt den HTTP-Statuscode 502 (Bad Gateway) an den Viewer zurück.
-
Connection -
Expect -
Keep-Alive -
Proxy-Authenticate -
Proxy-Authorization -
Proxy-Connection -
Trailer -
Upgrade -
X-Accel-Buffering -
X-Accel-Charset -
X-Accel-Limit-Rate -
X-Accel-Redirect -
X-Amz-Cf-* -
X-Amzn-Auth -
X-Amzn-Cf-Billing -
X-Amzn-Cf-Id -
X-Amzn-Cf-Xff -
X-Amzn-Errortype -
X-Amzn-Fle-Profile -
X-Amzn-Header-Count -
X-Amzn-Header-Order -
X-Amzn-Lambda-Integration-Tag -
X-Amzn-RequestId -
X-Cache -
X-Edge-* -
X-Forwarded-Proto -
X-Real-IP
Schreibgeschützte Header
Die folgenden Header sind schreibgeschützt. Ihre Funktion kann sie lesen und als Eingabe für die Funktionslogik verwenden, doch sie kann die Werte nicht ändern. Wenn Ihre Funktion einen schreibgeschützten Header hinzufügt oder bearbeitet, wird die Anfrage nicht von CloudFront validiert und CloudFront gibt den HTTP-Statuscode 502 (Bad Gateway) an den Viewer zurück.
Schreibgeschützte Header bei Viewer-Anforderungsereignissen
Die folgenden Header sind bei Viewer-Anforderungsereignissen schreibgeschützt.
-
Content-Length -
Host -
Transfer-Encoding -
Via
Schreibgeschützte Header in Ursprungsanforderungsereignissen (nur Lambda@Edge)
Die folgenden Header sind in Ursprungsanforderungsereignissen schreibgeschützt, die nur in Lambda@Edge vorhanden sind.
-
Accept-Encoding -
Content-Length -
If-Modified-Since -
If-None-Match -
If-Range -
If-Unmodified-Since -
Transfer-Encoding -
Via
Schreibgeschützte Header in Ursprungsantwortereignissen (nur Lambda@Edge)
Die folgenden Header sind in Ursprungsantwortereignissen schreibgeschützt, die nur in Lambda@Edge vorhanden sind.
-
Transfer-Encoding -
Via
Schreibgeschützte Header bei Viewer-Antwortereignissen
Die folgenden Header sind bei Viewer-Antwortereignissen schreibgeschützt, sowohl für CloudFront-Funktionen als auch für Lambda@Edge.
-
Warning -
Via
Die folgenden Header sind bei Viewer-Antwortereignissen für Lambda@Edge schreibgeschützt.
-
Content-Length -
Content-Encoding -
Transfer-Encoding
Abfragezeichenfolgen
Die folgenden Einschränkungen gelten für Funktionen, die eine Abfragezeichenfolge in einem Anforderungs-URI lesen, aktualisieren oder erstellen.
-
(Nur Lambda@Edge) Um auf die Abfragezeichenfolge in einer Ursprungsanforderung oder einer Ursprungsantwortfunktion zuzugreifen, muss die Cache-Richtlinie oder die Ursprungsanforderungsrichtlinie auf Alle auf Abfragezeichenfolgen gesetzt werden.
-
Eine Funktion kann eine Abfragezeichenfolge für Viewer-Anforderungs- und Ursprungsanforderungsereignisse erstellen oder aktualisieren (Ursprungsanforderungsereignisse existieren nur in Lambda@Edge).
-
Eine Funktion kann für Ursprungsantwort- und Viewer-Antwortereignisse eine Abfragezeichenfolge lesen, aber nicht erstellen oder aktualisieren (Ursprungsantwortereignisse existieren nur in Lambda@Edge).
-
Wenn eine Funktion eine Abfragezeichenfolge erstellt oder aktualisiert, gelten folgende Einschränkungen:
-
Die Abfragezeichenfolge darf keine Leerzeichen, Steuerzeichen oder die Fragment-ID (
#) enthalten. -
Die Gesamtgröße der URI und der Abfragezeichenfolge darf nicht mehr als 8.192 Zeichen umfassen.
-
Wir empfehlen die Verwendung der Prozentkodierung für die URI und die Abfragezeichenfolge. Weitere Informationen finden Sie unter URI-, Abfragezeichenfolge- und Header-Kodierung.
-
URI
Wenn eine Funktion Änderungen an dem URI für eine Anforderung durchführt, ändert dies weder das Cache-Verhalten für die Anforderung noch den Ursprung, an den Anforderung weitergeleitet wird.
Die Gesamtgröße der URI und der Abfragezeichenfolge darf nicht mehr als 8.192 Zeichen umfassen.
URI-, Abfragezeichenfolge- und Header-Kodierung
Die Werte für den URI, die Abfragezeichenfolge und die Header, die an Edge-Funktionen übergeben werden, sind UTF-8-kodiert. Ihre Funktion sollte UTF-8-Kodierung für die URI-, Abfragezeichenfolge- und Header-Werte verwenden, die sie zurückgibt. Die Prozentkodierung ist kompatibel mit der UTF-8-Kodierung kompatibel.
In der folgenden Liste wird erläutert, wie CloudFront die Kodierung für den URI, die Abfragezeichenfolge und die Header verarbeitet:
-
Wenn die Werte in der Anforderung UTF-8-kodiert sind, leitet CloudFront die Werte an Ihre Funktion weiter, ohne sie zu ändern.
-
Wenn Werte in der Anforderung ISO-8859-1-kodiert
sind, konvertiert CloudFront die Werte in UTF-8-Kodierung, bevor sie an Ihre Funktion weitergeleitet werden. -
Wenn Werte in der Anforderung mit einer anderen Zeichenkodierung kodiert sind, geht CloudFront davon aus, dass sie ISO-8859-1-kodiert sind, und versucht, eine Konvertierung von ISO-8859-1 zu UTF-8 durchzuführen.
Wichtig
Die konvertierten Zeichen sind möglicherweise eine falsche Interpretation der Werte in der ursprünglichen Anfrage. Dies kann dazu führen, dass Ihre Funktion oder Ihr Ursprung ein unbeabsichtigtes Ergebnis produzieren.
Die Werte für den URI, die Abfragezeichenfolge und die Header, die CloudFront an Ihren Ursprung weiterleitet, hängen davon ab, ob eine Funktion die Werte ändert:
-
Wenn eine Funktion den URI, die Abfragezeichenfolge oder den Header nicht ändert, leitet CloudFront die in der Anforderung erhaltenen Werte an Ihren Ursprung weiter.
-
Wenn eine Funktion den URI, die Abfragezeichenfolge oder den Hader ändert, leitet CloudFront die UTF-8-kodierten Werte weiter.
Microsoft Smooth Streaming
Sie können Edge-Funktionen nicht mit einer CloudFront-Distribution verwenden, die Sie für das Streaming von Mediendateien verwenden, die in das Format Microsoft Smooth Streaming transkodiert wurden.
Tagging
Sie können keine Tags zu Edge-Funktionen hinzufügen. Weitere Informationen zum Tagging in CloudFront finden Sie unter Markieren einer Distribution.
