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 Edge-Funktionen In den folgenden Themen werden die Einschränkungen beschrieben, die für CloudFront Functions und Lambda@Edge gelten. Einige Einschränkungen gelten für alle Edge-Funktionen, andere gelten nur für CloudFront Functions oder Lambda@Edge. Jedes Thema enthält detaillierte Informationen zu den Einschränkungen, die Sie bei der Entwicklung und Bereitstellung von Edge-Funktionen mit CloudFront berücksichtigen sollten. Machen Sie sich mit diesen Einschränkungen vertraut, um sicherzustellen, dass Ihre Edge-Funktionen wie erwartet funktionieren und den unterstützten Features entsprechen. **Topics** + [Einschränkungen für alle Edge-Funktionen](edge-function-restrictions-all.md) + [Einschränkungen für CloudFront Functions](cloudfront-function-restrictions.md) + [Einschränkungen für Lambda@Edge](lambda-at-edge-function-restrictions.md) Weitere Informationen zu Kontingenten (auch zuvor Limits genannt) finden Sie unter [Kontingente für CloudFront Funktionen](cloudfront-limits.md#limits-functions) und [Kontingente für Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge). # 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. **Topics** + [AWS-Konto-Eigentümerschaft](#function-restrictions-account-ownership) + [Kombinieren von CloudFront Functions mit Lambda@Edge](#function-restrictions-combining-functions) + [HTTP-Statuscodes](#function-restrictions-status-codes) + [HTTP-Header](#function-restrictions-headers) + [Abfragezeichenfolgen](#function-restrictions-query-strings) + [URI](#function-restrictions-uri) + [URI-, Abfragezeichenfolge- und Header-Kodierung](#function-restrictions-encoding) + [Microsoft Smooth Streaming](#function-restrictions-microsoft-smooth-streaming) + [Tagging](#function-restrictions-tagging) ## 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. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonCloudFront/latest/DeveloperGuide/edge-function-restrictions-all.html) ## 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](lambda-generating-http-responses.md#lambda-updating-http-responses). ## 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. **Topics** + [Unzulässige Header](#function-restrictions-disallowed-headers) + [Schreibgeschützte Header](#function-restrictions-read-only-headers) ### 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](#function-restrictions-encoding). ## 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](https://en.wikipedia.org/wiki/ISO/IEC_8859-1) 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](tagging.md). # Einschränkungen für CloudFront Functions Die folgenden Einschränkungen gelten nur für CloudFront Functions. **Contents** + [Logs (Protokolle)](#cloudfront-function-restrictions-logs) + [Anforderungstext](#cloudfront-function-restrictions-request-body) + [Verwenden temporärer Anmeldeinformationen mit der CloudFront-KeyValueStore-API](#regional-endpoint-for-key-value-store) + [Laufzeit](#cloudfront-function-runtime-restrictions) + [Computing-Auslastung](#cloudfront-function-restrictions-compute-utilization) Weitere Informationen zu Kontingenten (zuvor Limits genannt) finden Sie unter [Kontingente für CloudFront Funktionen](cloudfront-limits.md#limits-functions). ## Logs (Protokolle) Funktionsprotokolle in CloudFront Functions werden auf 10 KB gekürzt. ## Anforderungstext CloudFront Functions kann nicht auf den Text der HTTP-Anforderung zugreifen. ## Verwenden temporärer Anmeldeinformationen mit der CloudFront-KeyValueStore-API Sie können AWS -Security-Token-Service (AWS STS) verwenden, um temporäre Sicherheitsanmeldeinformationen (auch als *Sitzungstoken* bezeichnet) zu generieren. Mit Sitzungstoken können Sie vorübergehend eine AWS Identity and Access Management (IAM)-Rolle übernehmen, sodass Sie auf AWS-Services zugreifen können. Um die [CloudFront-KeyValueStore-API](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_Operations_Amazon_CloudFront_KeyValueStore.html) aufzurufen, verwenden Sie einen *regionalen* Endpunkt in AWS STS, um ein Sitzungstoken der *Version 2* zurückzugeben. Wenn Sie den *globalen* Endpunkt für AWS STS (`sts.amazonaws.com`) verwenden, generiert AWS STS ein Sitzungstoken der *Version 1*, das von Signature Version 4A (SigV4A) nicht unterstützt wird. Infolgedessen wird ein Authentifizierungsfehler angezeigt. Die CloudFront-KeyValueStore-API können Sie anhand der folgenden Optionen aufrufen: **AWS CLI und AWS SDKs** Sie können die AWS CLI oder ein AWS SDK für die Verwendung regionaler AWS STS-Endpunkte konfigurieren. Weitere Informationen finden Sie unter [AWS STS-regionalisierte Endpunkte](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html) im *Referenzhandbuch für AWS SDK und Tools*. Weitere Informationen zu verfügbaren AWS STS-Endpunkten finden Sie unter [Regionen und Endpunkte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#id_credentials_region-endpoints) im *IAM-Benutzerhandbuch*. **SAML** Sie können SAML für die Verwendung regionaler AWS STS-Endpunkte konfigurieren. Weitere Informationen finden Sie im Blogbeitrag [How to use regional SAML endpoints for failover](https://aws.amazon.com/blogs/security/how-to-use-regional-saml-endpoints-for-failover/). **`SetSecurityTokenServicePreferences`-API** Anstatt einen regionalen AWS STS-Endpunkt zu verwenden, können Sie den globalen Endpunkt für AWS STS so konfigurieren, dass Sitzungstoken der Version 2 zurückgegeben werden. Verwenden Sie dazu die API-Operation [SetSecurityTokenServicePreferences](https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html), um Ihr AWS-Konto zu konfigurieren. **Example Beispiel: IAM-CLI-Befehl** ``` aws iam set-security-token-service-preferences --global-endpoint-token-version v2Token ``` Es wird empfohlen, die regionalen AWS STS-Endpunkte anstelle dieser Option zu verwenden. Regionale Endpunkte bieten eine höhere Verfügbarkeit und Failover-Szenarien. **Benutzerdefinierter Identitätsanbieter** Wenn Sie einen benutzerdefinierten Identitätsanbieter verwenden, der sich um den Verbund kümmert und die Rolle übernimmt, verwenden Sie eine der vorherigen Optionen für das übergeordnete Identitätsanbietersystem, das für die Generierung des Sitzungstokens verantwortlich ist. ## Laufzeit Die Laufzeitumgebung von CloudFront Functions unterstützt keine dynamische Codeauswertung und schränkt den Zugriff auf Netzwerk, Dateisystem, Umgebungsvariablen und Timer ein. Weitere Informationen finden Sie unter [Eingeschränkte Funktionen](functions-javascript-runtime-10.md#writing-functions-javascript-features-restricted-features). **Anmerkung** Um CloudFront KeyValueStore verwenden zu können, muss Ihre CloudFront-Funktion die [JavaScript-Laufzeitumgebung 2.0](functions-javascript-runtime-20.md) verwenden. ## Computing-Auslastung CloudFront-Funktionen haben eine Begrenzung der Zeit, die sie für die Ausführung benötigen können, gemessen als *Computing-Auslastung*. Die Computing-Auslastung ist eine Zahl zwischen 0 und 100, mit der die Zeit angegeben wird, die die Ausführung der Funktion als Prozentsatz der maximal zulässigen Zeit in Anspruch genommen hat. Zum Beispiel bedeutet eine Rechenauslastung von 35, dass die Funktion in 35 % der maximal zulässigen Zeit abgeschlossen wurde. Wenn Sie [eine Funktion testen](test-function.md) können Sie den Wert der Computing-Auslastung in der Ausgabe des Testereignisses sehen. Für Produktionsfunktionen können Sie die [Metrik für die Computing-Auslastung](viewing-cloudfront-metrics.md#monitoring-console.cloudfront-functions) auf der [Seite Monitoring (Überwachung) in der CloudFront-Konsole](https://console.aws.amazon.com/cloudfront/v4/home?#/monitoring) oder in CloudWatch anzeigen. # Einschränkungen für Lambda@Edge Die folgenden Einschränkungen gelten nur für Lambda@Edge. **Contents** + [DNS-Auflösung](#lambda-at-edge-restrictions-dns) + [HTTP-Statuscodes](#lambda-at-edge-restrictions-status-codes) + [Version der Lambda-Funktion](#lambda-at-edge-restrictions-version) + [Lambda-Region](#lambda-at-edge-restrictions-region) + [Lambda-Rollenberechtigungen](#lambda-at-edge-restrictions-role-permissions) + [Lambda-Funktionen](#lambda-at-edge-restrictions-features) + [Unterstützte Laufzeiten](#lambda-at-edge-restrictions-runtime) + [CloudFront-Header](#lambda-at-edge-restrictions-cloudfront-headers) + [Einschränkungen für Anforderungstext mit der Option „Text einschließen“](#lambda-at-edge-restrictions-request-body) + [Antwort-Timeout und Keep-Alive-Timeout (nur benutzerdefinierte Ursprünge)](#timeout-for-lambda-edge-functions) Hinweise zu -Kontingenten finden Sie unter [Kontingente für Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge). ## DNS-Auflösung CloudFront führt für den Ursprungsdomainnamen eine DNS-Auflösung durch, *bevor* die Lambda@Edge-Funktion der Ursprungsanforderung ausgeführt wird. Wenn Probleme mit dem DNS-Service für Ihre Domain auftreten und CloudFront den Domainnamen nicht auflösen kann, um die IP-Adresse abzurufen, wird Ihre Lambda@Edge-Funktion nicht aufgerufen. CloudFront gibt den [HTTP-Statuscode 502 (Bad Gateway)](http-502-bad-gateway.md) an den Client zurück. Weitere Informationen finden Sie unter [DNS-Fehler (`NonS3OriginDnsError`)](http-502-bad-gateway.md#http-502-dns-error). Wenn Ihre Funktionslogik den Ursprungsdomainnamen ändert, führt CloudFront nach Ausführung der Funktion eine weitere DNS-Auflösung für den aktualisierten Domainnamen durch. Weitere Informationen zur Verwaltung des DNS-Failovers finden Sie unter [Konfigurieren von DNS-Failover](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) im *Entwicklerhandbuch für Amazon Route 53*. ## HTTP-Statuscodes Lambda@Edge-Funktionen für Viewer-Antwortereignisse können den HTTP-Statuscode der Antwort nicht ändern, unabhängig davon, ob die Antwort vom Ursprung oder vom CloudFront-Cache stammt. ## Version der Lambda-Funktion Sie müssen eine nummerierte Version der Lambda-Funktion verwenden, nicht jedoch `$LATEST` oder Aliase. ## Lambda-Region Die Lambda-Funktion muss sich in der Region USA Ost (Nord-Virginia) befinden. ## Lambda-Rollenberechtigungen Um Auslöser hinzufügen zu können, muss die Ihrer Lambda-Funktion zugewiesene IAM-Ausführungsrolle von den Haupt-Services `lambda.amazonaws.com` und `edgelambda.amazonaws.com` eingenommen werden können. Weitere Informationen finden Sie unter [Einrichten von IAM-Berechtigungen und -Rollen für Lambda@Edge](lambda-edge-permissions.md). ## Lambda-Funktionen Die folgenden Lambda-Funktionen werden von Lambda@Edge nicht unterstützt: + Andere [Lambda-Laufzeit-Verwaltungskonfigurationen](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-update.html#runtime-management-controls) als **Automatisch** (Standard) + Konfiguration Ihrer Lambda-Funktion für den Zugriff auf Ressourcen in Ihrer VPC + [Lambda-Funktion für Warteschlangen für unzustellbare Nachrichten](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#dlq) + [Lambda-Umgebungsvariablen](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html) (mit Ausnahme von reservierten Umgebungsvariablen, die automatisch unterstützt werden) + Lambda-Funktionen mit dem [Verwalten von AWS Lambda-Abhängigkeiten mit Ebenen](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) + [Verwenden von AWS X-Ray](https://docs.aws.amazon.com/lambda/latest/dg/lambda-x-ray.html) + Parallelität per Lambda **Anmerkung** Lambda@Edge-Funktionen nutzen dieselben [regionalen Parallelitätsfunktionen](https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html) wie alle Lambda-Funktionen. Weitere Informationen finden Sie unter [Kontingente für Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge). + [Erstellen einer Lambda-Funktion mit einem Container-Image](https://docs.aws.amazon.com/lambda/latest/dg/images-create.html) + [Lambda-Funktionen, die die arm64-Architektur verwenden](https://docs.aws.amazon.com/lambda/latest/dg/foundation-arch.html) + Lambda-Funktionen mit mehr als 512 MB flüchtigem Speicher + Verwenden eines [kundenseitig verwalteten Schlüssels zur Verschlüsselung Ihrer ZIP-Bereitstellungspakete](https://docs.aws.amazon.com/lambda/latest/dg/encrypt-zip-package.html) ## Unterstützte Laufzeiten Lambda@Edge unterstützt die neuesten Versionen von Node.js und Python-Laufzeiten. Eine Liste der unterstützten Versionen und ihrer zukünftiger Verfallsdaten finden Sie unter [Unterstützte Laufzeiten](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html#runtimes-supported) im *Entwicklerhandbuch für AWS Lambda*. **Tipp** Es hat sich bewährt, die neuesten Versionen der bereitgestellten Laufzeiten für Leistungsverbesserungen und neue Funktionen zu verwenden. Sie können mit veralteten Version von Node.js keine Funktionen erstellen oder aktualisieren. Sie können bestehende Funktionen dieser Versionen nur mit CloudFront-Distributionen verknüpfen. Funktionen dieser Versionen, die Distributionen zugeordnet sind, werden weiterhin ausgeführt. Wir empfehlen jedoch, Ihre Funktion auf neuere Versionen von Node.js zu verschieben. Weitere Informationen finden Sie unter [Richtlinie für den Laufzeitablauf](https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html) im *Entwicklerhandbuch für AWS Lambda* und im [Node.js-Release-Zeitplan](https://github.com/nodejs/Release#release-schedule) auf GitHub. ## CloudFront-Header Lambda@Edge-Funktionen können jeden der in [Hinzufügen von CloudFront-Anforderungsheadern](adding-cloudfront-headers.md) aufgeführten CloudFront-Header lesen, bearbeiten, entfernen oder hinzufügen. **Hinweise** Wenn CloudFront diese Header hinzufügen soll, müssen Sie CloudFront so konfigurieren, dass sie mithilfe einer [Cache-Richtlinie](controlling-the-cache-key.md) oder [Ursprungsanforderungsrichtlinie](controlling-origin-requests.md) hinzugefügt werden. CloudFront fügt die Header *nach* dem Viewer-Anforderungsereignis hinzu, was bedeutet, dass sie Lambda@Edge-Funktionen in einer Viewer-Anforderungsfunktion nicht zur Verfügung stehen. Die Header sind nur für Lambda@Edge-Funktionen in einer Ursprungsanfrage und einer Ursprungsantwort verfügbar. Wenn die Viewer-Anforderung Header mit diesen Namen enthält und Sie CloudFront so konfiguriert haben, dass diese Header mithilfe einer [Cache-Richtlinie](controlling-the-cache-key.md) oder [Ursprungsanforderungsrichtlinie](controlling-origin-requests.md) hinzugefügt werden, überschreibt CloudFront die Header-Werte, die in der Viewer-Anforderung waren. Viewer-Funktionen sehen den Header-Wert aus der Viewer-Anforderung, während Funktionen, die mit Ursprüngen verbunden sind, den Header-Wert sehen, den CloudFront hinzugefügt hat. Wenn eine Viewer-Anforderungsfunktion den Header `CloudFront-Viewer-Country` hinzufügt, schlägt die Validierung fehl und CloudFront gibt den HTTP-Statuscode 502 (Bad Gateway) an den Viewer zurück. ## Einschränkungen für Anforderungstext mit der Option „Text einschließen“ Wenn Sie die Option **Text einschließen** auswählen, um den Anforderungstext an die Lambda@Edge-Funktion weiterzugeben, beachten Sie die folgenden Informationen und Größenbeschränkungen für die Teile des Textes, die offengelegt oder ersetzt werden. + CloudFront base64-kodiert immer den Anforderungstext, bevor er Lambda@Edge zur Verfügung stellt. + Wenn der Anforderungs-Fließtext sehr umfangreich ist, wird er von CloudFront vor der Weitergabe an Lambda@Edge wie folgt abgeschnitten: + Bei Viewer-Anforderungsereignissen wird der Fließtext bei 40 KB abgeschnitten. + Bei Ursprungsanforderungsereignissen wird der Fließtext bei 1 MB abgeschnitten. + Wenn Sie schreibgeschützt auf den Anforderungs-Fließtext zugreifen, sendet CloudFront den gesamten ursprünglichen Anforderungs-Fließtext an den Ursprung. + Wenn Ihre Lambda@Edge-Funktion den Anforderungstext ersetzt, gelten die folgenden Größenbeschränkungen für den Text, den die Funktion zurückgibt: + Wenn die Lambda@Edge-Funktion den Textkörper als Klartext zurückgibt: + Bei Viewer-Anforderungsereignissen ist der Text auf 40 KB beschränkt. + Bei Ursprungsanforderungsereignissen ist der Text auf 1 MB beschränkt. + Wenn die Lambda@Edge Funktion den Textkörper als base64-codierten Text zurückgibt: + Bei Viewer-Anforderungsereignissen ist der Text auf 53,2 KB beschränkt. + Bei Ursprungsanforderungsereignissen ist der Text auf 1,33 MB beschränkt. **Anmerkung** Wenn Ihre Lambda@Edge-Funktion einen Text zurückgibt, der diese Grenzwerte überschreitet, schlägt Ihre Anforderung mit dem HTTP-Statuscode 502 ([Lambda-Validierungsfehler](http-502-bad-gateway.md#http-502-lambda-validation-error)) fehl. Wir empfehlen Ihnen, Ihre Lambda@Edge-Funktion so zu aktualisieren, dass der Text diese Grenzwerte nicht überschreitet. ## Antwort-Timeout und Keep-Alive-Timeout (nur benutzerdefinierte Ursprünge) Wenn Sie Lambda@Edge-Funktionen verwenden, um das Antwort-Timeout oder das Keep-Alive-Timeout für Ihre Distributionsursprünge festzulegen, stellen Sie sicher, dass Sie einen Wert angeben, den Ihr Ursprung unterstützen kann. Weitere Informationen finden Sie unter [Kontingent für Antwort- und Keep-Alive-Timeout](DownloadDistValuesOrigin.md#response-keep-alive-timeout-quota).