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.

AWS-Konto -Eigentümerschaft

Um eine Edge-Funktion einer CloudFront Distribution zuzuordnen, müssen die Funktion und die Distribution derselben AWS-Konto gehören.

CloudFront Funktionen mit Lambda @Edge kombinieren

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.

• Sie können CloudFront Functions und Lambda @Edge nicht in Viewer-Ereignissen (Viewer-Anfrage und Viewer-Antwort) kombinieren.

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 Zuschauer-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 Sie HTTP-Antworten in den ursprünglichen Antwortauslö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 Funktionen sie lesen, aber nicht hinzufügen, ändern oder löschen können.

Themen

• Unzulässige Header

• Schreibgeschützte Header

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 Funktion einen dieser Header hinzufügt, schlägt sie bei der CloudFront Überprüfung fehl 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, schlägt die CloudFront Überprüfung der Anforderung fehl 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 in Viewer-Antwortereignissen sowohl für CloudFront Functions als auch für Lambda @Edge schreibgeschützt.

• 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 Kodierung von URI, Abfragezeichenfolge und Headern.

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.

Kodierung von URI, Abfragezeichenfolge und Headern

Die Werte für den URI, die Abfragezeichenfolge und die Header, die an Edge-Funktionen übergeben werden, sind UTF-8-kodiert. Ihre Funktion sollte die UTF-8-Kodierung für die von ihr zurückgegebenen URI-, Abfragezeichenfolgen- und Header-Werte verwenden. Die Prozentkodierung ist kompatibel mit der UTF-8-Kodierung kompatibel.

In der folgenden Liste wird erklärt, wie CloudFront mit der Kodierung für den URI, die Abfragezeichenfolge und die Header umgegangen wird:

• Wenn die Werte in der Anfrage UTF-8-kodiert sind, werden die Werte an Ihre CloudFront Funktion weitergeleitet, ohne sie zu ändern.

• Wenn die Werte in der Anfrage ISO-8859-1-codiert sind, werden die Werte in die UTF-8-Kodierung CloudFront konvertiert, bevor sie an Ihre Funktion weitergeleitet werden.

• Wenn Werte in der Anfrage mit einer anderen Zeichenkodierung codiert sind, wird CloudFront davon ausgegangen, dass sie ISO-8859-1-kodiert sind, und versucht, sie von ISO-8859-1 nach UTF-8 zu konvertieren.

  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 an Ihren Ursprung weitergeleitet werden, hängen davon ab, ob eine Funktion die CloudFront Werte ändert:

• Wenn eine Funktion den URI, die Abfragezeichenfolge oder den Header nicht ändert, CloudFront leitet sie die Werte, die sie in der Anfrage erhalten hat, an Ihren Ursprung weiter.

• Wenn eine Funktion den URI, die Abfragezeichenfolge oder den Header ändert, CloudFront leitet sie die UTF-8-kodierten Werte weiter.

Microsoft Smooth Streaming

Sie können Edge-Funktionen nicht mit einer CloudFront Distribution verwenden, die Sie zum Streamen von Mediendateien verwenden, die Sie in das Microsoft Smooth Streaming-Format transkodiert haben.

Tagging

Sie können Edge-Funktionen keine Tags hinzufügen. Weitere Informationen zum Taggen in finden Sie CloudFront unterKennzeichnen Sie eine Distribution.