Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

413 Anfrageentität zu groß – TooBigBody

Sie lesen gerade die Dokumentation zu Apigee Edge.
Apigee X-Dokumentation aufrufen info

Symptom

Die Clientanwendung erhält den HTTP-Statuscode 413 Request Entity Too Large mit dem Fehlercode protocol.http.TooBigBody als Antwort auf API-Aufrufe.

Fehlermeldung

Die Clientanwendung erhält den folgenden Antwortcode:

HTTP/1.1 413 Request Entity Too Large

Außerdem wird möglicherweise die folgende Fehlermeldung angezeigt:

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

Mögliche Ursachen

Dieser Fehler tritt auf, wenn die Nutzlastgröße, die von der Clientanwendung als Teil der HTTP-Anfrage an Apigee Edge gesendet wird, größer als das zulässige Limit in Apigee Edge ist .

Mögliche Ursachen für diesen Fehler :

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Größe der Anfragenutzlast überschreitet das zulässige Limit	Die Nutzlastgröße, die von der Clientanwendung als Teil der HTTP-Anfrage an Apigee Edge gesendet wird, überschreitet das zulässige Limit in Apigee Edge.	Nutzer der Edge Public und Private Cloud
Größe der Anfragenutzlast überschreitet nach der Dekomprimierung das zulässige Limit	Die Nutzlastgröße, die von der Clientanwendung als Teil der HTTP-Anfrage an Apigee Edge im komprimierten Format gesendet wird, überschreitet das zulässige Limit, wenn sie von Apigee Edge dekomprimiert wird.	Nutzer der Edge Public und Private Cloud

Allgemeine Diagnoseschritte

Verwenden Sie eines der folgenden Tools oder Verfahren, um diesen Fehler zu diagnostizieren:

API-Monitoring

So diagnostizieren Sie den Fehler mit API Monitoring:

Bei der Apigee Edge-Benutzeroberfläche anmelden als Nutzer mit einer geeigneten Rolle.
Wechseln Sie zu der Organisation, in der Sie das Problem untersuchen möchten.
Rufen Sie die Seite Analysieren > API-Monitoring > Untersuchen auf.
Wählen Sie den Zeitraum aus, in dem die Fehler aufgetreten sind.
Sie können den Filter Proxy auswählen, um den Fehlercode einzugrenzen.
Stellen Sie den Fehlercode im Vergleich zur Zeit dar.
Wählen Sie eine Zelle mit dem Fehlercode protocol.http.TooBigBody und dem Statuscode 413 aus, wie unten dargestellt:
Informationen zum Fehlercode protocol.http.TooBigBody werden wie unten dargestellt angezeigt:
Klicken Sie auf Logs ansehen und maximieren Sie die Zeile für die fehlgeschlagene Anfrage. Notieren Sie sich dann im Fenster Logs die Details wie unten dargestellt :
Unkomprimiert

Szenario 1: Anfragenutzlast wird unkomprimiert gesendet

Notieren Sie sich im Fenster „Logs“ die folgenden Details:
- Statuscode:413
- Fehlerquelle: proxy
- Fehlercode:protocol.http.TooBigBody.
- Länge der Anfrage(in Byte): 15360440 (~15 MB)
Wenn Fault Source den Wert proxy, Fault Code den Wert protocol.http.TooBigBody und Request Length mehr als 10 MB hat, bedeutet das, dass die HTTP-Anfrage des Clients eine Nutzlastgröße hat, die das zulässige Limit in Apigee überschreitet.
Komprimiert

Szenario 2: Anfragenutzlast wird in komprimierter Form gesendet

Notieren Sie sich im Fenster Logs die folgenden Details:
- Statuscode:413
- Fehlerquelle: proxy
- Fehlercode:protocol.http.TooBigBody.
- Anfragelänge(Byte): 15264 (~15 KB)
Wenn die Fehlerquelle den Wert proxy, der Fehlercode den Wert protocol.http.TooBigBody und die Anfragelänge weniger als 10 MB hat, bedeutet das, dass die HTTP-Anfrage vom Client eine Anfragenutzlastgröße hat, die im komprimierten Format unter dem zulässigen Limit liegt, die Nutzlastgröße jedoch größer als das zulässige Limit ist, wenn sie von Apigee dekomprimiert wird.

Trace

So diagnostizieren Sie den Fehler mit dem Trace-Tool:

Aktivieren Sie die Trace-Sitzung und entweder
- Warten Sie, bis der Fehler 413 Request Entity Too Large auftritt, oder
- Wenn Sie das Problem reproduzieren können, führen Sie den API-Aufruf aus und reproduzieren Sie den 413 Request Entity Too Large-Fehler.
Achte darauf, dass Alle Flow-Informationen anzeigen aktiviert ist.
Wählen Sie eine der fehlgeschlagenen Anfragen aus und sehen Sie sich den Trace an.
Rufen Sie die Phase Anfrage vom Kunden erhalten auf.
Unkomprimiert

Szenario 1: Anfragenutzlast wird unkomprimiert gesendet

Wichtige Hinweise:
- Content-Encoding:nicht vorhanden
- Content-Length: 15360204
Komprimiert

Szenario 2: Anfragenutzlast wird in komprimierter Form gesendet

Wichtige Hinweise:
- Content-Encoding: gzip
- Content-Length: 14969
- Content-Type:application/x-gzip
Navigieren Sie durch die verschiedenen Phasen des Traces und suchen Sie nach der Stelle, an der der Fehler aufgetreten ist.
Der Fehler tritt in der Regel in einem Ablauf nach der Phase Request Received from Client auf, wie unten dargestellt:
Notieren Sie sich den Wert des Fehlers aus dem Trace. Der oben gezeigte Beispiel-Trace zeigt Folgendes:
- Fehler: Body buffer overflow
- error.class::com.apigee.errors.http.user.RequestTooLarge
Rufen Sie Response Sent to Client auf und notieren Sie sich die Werte des Fehlers aus dem Trace. Der Beispiel-Trace unten zeigt Folgendes:
- Fehler: 413 Request Entity Too Large
- Fehlerhafter Inhalt: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
Suchen Sie im Trace nach der Phase AX (Analytics Data Recorded) und klicken Sie darauf.
Scrollen Sie im Abschnitt Phasendetails nach unten zu Gelesene Variablen.
Ermitteln Sie den Wert der Variablen client.received.content.length , die Folgendes angibt:
- Die tatsächliche Größe der Anfragenutzlast, wenn sie im unkomprimierten Format gesendet wird, und
- Die Größe der Anforderungsnutzlast nach der Dekomprimierung durch Apigee, wenn die Nutzlast im komprimierten Format gesendet wird. Er ist in diesem Szenario immer derselbe wie der Wert des zulässigen Limits (10 MB).
Hinweis:Möglicherweise ist ein Content-Length-Fehlerheader vorhanden, der die Größe der Fehler-Nutzlast und nicht der Anfragenutzlast angibt. Bei diesem Fehler muss der in der Variablen client.received.content.length angegebene Wert berücksichtigt werden.

Unkomprimiert

Szenario 1: Nutzlast der Anfrage in unkomprimierter Form

Variable „client.received.content.length“: 15360204

Komprimiert

Szenario 2: Nutzlast der Anfrage im komprimierten Format

Variable „client.received.content.length“: 10489856

In der folgenden Tabelle wird erläutert, warum der Fehler 413 von Apigee in den beiden Szenarien basierend auf dem Wert der Variablen client.received.content.length zurückgegeben wird:

Szenario	Wert von „client.received.content.length“	Grund für den Fehler
Anfragenutzlast im unkomprimierten Format	~15 MB	Die Größe überschreitet das zulässige Limit von 10 MB.
Anfragenutzlast im komprimierten Format	~10 MB	Größenbeschränkung nach der Dekomprimierung überschritten Hinweis:Die tatsächliche Größe der Nutzlast nach der Dekomprimierung kann deutlich mehr als 10 MB betragen. Apigee beendet die Dekomprimierung jedoch, sobald die Größe der dekomprimierten Daten das Limit von 10 MB (Standardlimit) überschreitet, und gibt den Fehler zurück.

NGINX

So diagnostizieren Sie den Fehler mithilfe von NGINX-Zugriffslogs:

Wenn Sie Private Cloud-Nutzer sind, können Sie die NGINX-Zugriffsprotokolle verwenden, um die wichtigsten Informationen zu HTTP-413-Fehlern zu ermitteln.
NGINX-Zugriffslogs prüfen:

/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

Hinweis:Ersetzen Sie ORG, ENV und PORT# durch tatsächliche Werte.
Suchen Sie nach 413-Fehlern in einem bestimmten Zeitraum (wenn das Problem in der Vergangenheit aufgetreten ist) oder danach, ob bei Anfragen immer noch 413-Fehler auftreten.

Wenn Sie 413-Fehler mit dem X-Apigee-fault-code finden, der mit dem Wert von protocol.http.TooBigBody übereinstimmt, ermitteln Sie den Wert von X-Apigee-fault-source.

Unkomprimiert

Szenario 1 : Größe der Anfragenutzlast im unkomprimierten Format

Der obige Beispiel-Eintrag aus dem NGINX-Zugriffslog hat die folgenden Werte für X-Apigee-fault-code und X-Apigee-fault-source:

Antwortheader	Wert
X-Apigee-fault-code	`protocol.http.TooBigBody`
X-Apigee-fault-sourc	`policy`

Beachten Sie die Anfragelänge:15360440 (14,6 MB > zulässiges Limit)

Komprimiert

Szenario 2 : Größe der Anfragenutzlast im komprimierten Format

Der obige Beispiel-Eintrag aus dem NGINX-Zugriffslog hat die folgenden Werte für X-Apigee-fault-code und X-Apigee-fault-source:

Antwortheader	Wert
X-Apigee-fault-code	`protocol.http.TooBigBody`
X-Apigee-fault-source	`policy`

Beachten Sie die Anfragelänge:15264 (14,9 K < zulässiges Limit)

In diesem Szenario gibt Apigee Edge 413 zurück, obwohl die Request Length (Anfragelänge) unter dem zulässigen Limit liegt. Das liegt daran, dass die Anfrage möglicherweise im komprimierten Format gesendet wurde und die Größe der Nutzlast nach der Dekomprimierung durch Apigee Edge das Limit überschreitet.

Ursache: Die Größe der Request-Nutzlast überschreitet das zulässige Limit.

Diagnose

Ermitteln Sie den Fehlercode, die Fehlerquelle und die Größe der Anfrage-Payload für den beobachteten Fehler. Verwenden Sie dazu API-Monitoring, das Trace-Tool oder NGINX-Zugriffsprotokolle, wie in Häufige Diagnoseschritte in Szenario 1 (nicht komprimiert) beschrieben.
Wenn die Fehlerquelle den Wert policy oder proxy hat, bedeutet dies, dass die Größe der von der Clientanwendung an Apigee gesendeten Anfrage-Nutzlast das zulässige Limit in Apigee Edge überschreitet.
Prüfen Sie die Größe der Anfragenutzlast, die in Schritt 1 ermittelt wurde.
- Wenn die Nutzlastgröße das zulässige Limit von 10 MB überschreitet, ist dies die Ursache des Fehlers.
- Wenn die Nutzlastgröße das zulässige Limit von 10 MB nicht überschreitet, wird die Anfragenutzlast möglicherweise im komprimierten Format übergeben. Ursache: Größe der Anfragenutzlast überschreitet nach der Dekomprimierung das zulässige Limit
Sie können auch prüfen, ob die Größe der Anfrage-Nutzlast tatsächlich das zulässige Limit von > 10 MB überschreitet. Gehen Sie dazu so vor:
1. Wenn Sie keinen Zugriff auf die tatsächliche Anfrage der Clientanwendung haben, fahren Sie mit Lösung fort.
2. Wenn Sie Zugriff auf die tatsächliche Anfrage der Clientanwendung haben, führen Sie die folgenden Schritte aus:
  1. Prüfen Sie die Größe der Nutzlast, die in der Anfrage übergeben wird.
  2. Wenn die Größe der Nutzlast das in Apigee Edge zulässige Limit überschreitet, ist dies die Ursache des Problems.

Auflösung

Gehen Sie zu Lösung.

Ursache: Die Größe der Anfragenutzlast überschreitet nach der Dekomprimierung das zulässige Limit.

Wenn die Anfrage-Nutzlast im komprimierten Format gesendet wird und der Anfrageheader Content-Encoding auf gzip, gesetzt ist, dekomprimiert Apigee die Anfrage-Nutzlast. Wenn Apigee während der Dekomprimierung feststellt, dass die Größe der Nutzlast 10 MB überschreitet ( das zulässige Limit), wird die Dekomprimierung beendet und sofort mit 413 Request Entity Too Large und dem Fehlercode protocol.http.TooBigBody geantwortet.

Diagnose

Ermitteln Sie den Fehlercode, die Fehlerquelle und die Größe der Anfrage-Nutzlast für den beobachteten Fehler mithilfe von API Monitoring, Trace Tool oder NGINX-Zugriffsprotokollen, wie in Häufige Diagnoseschritte unter Szenario 2 (komprimiert) beschrieben.
Wenn die Fehlerquelle den Wert policy oder proxy hat, bedeutet dies, dass die Größe der Anfrage-Nutzlast, die von der Clientanwendung an Apigee gesendet wird, das zulässige Limit in Apigee Edge überschreitet.
Prüfen Sie die Größe der Anfragenutzlast, die in Schritt 1 ermittelt wurde.
- Wenn die Nutzlastgröße das zulässige Limit von 10 MB überschreitet, ist dies die Ursache des Fehlers.
- Wenn die Nutzlastgröße das zulässige Limit von 10 MB nicht überschreitet, wird die Anfragenutzlast möglicherweise im komprimierten Format übergeben. Prüfen Sie in diesem Fall die unkomprimierte Größe der komprimierten Nutzlast der Anfrage.
Sie können mit einer der folgenden Methoden prüfen, ob die Anfrage vom Client im komprimierten Format gesendet wurde und die unkomprimierte Größe das zulässige Limit überschritten hat:
Trace

So validieren Sie mit dem Trace-Tool:
1. Wenn Sie einen Trace für die fehlgeschlagene Anfrage erfasst haben, folgen Sie der Anleitung unter Trace und
  1. Wert der Variablen client.received.content.length ermitteln
  2. Prüfen Sie, ob die Anfrage vom Client den Header Content-Encoding: gzip enthielt.
2. Wenn der Wert der Variablen client.received.content.length größer als 10 MB, dem zulässigen Limit, ist und der Anfrageheader Content-Encoding: gzip lautet, ist dies die Ursache für diesen Fehler.
Tatsächliche Anfrage

So validieren Sie die Anfrage:
1. Wenn Sie keinen Zugriff auf die tatsächliche Anfrage der Clientanwendung haben, fahren Sie mit Lösung fort.
2. Wenn Sie Zugriff auf die tatsächliche Anfrage der Clientanwendung haben, führen Sie die folgenden Schritte aus:
  1. Prüfen Sie die Größe der Nutzlast, die in der Anfrage übergeben wird, sowie den Content-Encoding-Header, der in der Anfrage gesendet wird.
  2. Prüfen Sie, ob die unkomprimierte Größe der Nutzlast das zulässige Limit in Apigee Edge überschreitet.
    
    Beispielanfrage:
    
    curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v
    
    Im obigen Fall ist die Datei test15mbfile.gz kleiner als das Größenlimit. Die Größe der unkomprimierten Datei test15mbfile beträgt jedoch etwa 15 MB und der Content-Encoding-Header ist gzip.
    
    Wenn Sie einen anderen Client verwenden, rufen Sie die Clientprotokolle ab, um die gesendete Nutzlastgröße zu ermitteln und zu prüfen, ob der Content-Encoding-Header auf gzip gesetzt ist.
Logs des Message Processors

So validieren Sie die Einrichtung anhand von Message Processor-Logs:

Hinweis:Die Anleitung in diesem Abschnitt gilt nur für Nutzer von Edge Private Cloud.
1. Wenn Sie Private Cloud-Nutzer sind, können Sie die Message Processor-Logs verwenden, um die wichtigsten Informationen zu HTTP-413-Fehlern zu ermitteln.
2. Logs des Message Processors prüfen:
  
  /opt/apigee/var/log/edge-message-processor/logs/system.log
3. Suchen Sie nach 413-Fehlern in einem bestimmten Zeitraum (wenn das Problem in der Vergangenheit aufgetreten ist) oder nach Anfragen, bei denen weiterhin 413-Fehler auftreten.
  
  Sie können die folgenden Suchstrings verwenden:
  grep -ri "chunkCount"
  grep -ri "RequestTooLarge"
4. Sie finden Zeilen aus system.log, die den folgenden ähneln (TotalRead und chunkCount können in Ihrem Fall variieren):
  2021-07-06 13:29:57,544 NIOThread@1 ERROR HTTP.SERVICE - TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large. TotalRead 10489856 chunkCount 2570 2021-07-06 13:29:57,545 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace: com.apigee.errors.http.user.RequestTooLarge : Body buffer overflow
5. Während der Dekomprimierung wird der Vorgang beendet und die folgende Zeile ausgegeben, sobald der Message Processor feststellt, dass die Gesamtzahl der gelesenen Byte größer als 10 MB ist:
  Message is too large. TotalRead 10489856 chunkCount 2570
  Das bedeutet, dass die Größe der Anfrage-Nutzlast mehr als 10 MB beträgt und Apigee den Fehler RequestTooLarge mit dem Fehlercode protocol.http.TooBigBody ausgibt, wenn die Größe das Limit von 10 MB überschreitet.
  
  Hinweis:Die oben genannte Zeile wird in den Message Processor-Protokollen angezeigt, auch wenn Sie die Anfrage-Payload im unkomprimierten Format senden. Der einzige Unterschied besteht darin, dass TotalRead in diesem Szenario die tatsächliche Größe der Anfragenutzlast enthält.

Auflösung

Größe festlegen

Option 1 [Empfohlen]: Clientanwendung so korrigieren, dass keine Nutzlastgröße gesendet wird, die das zulässige Limit überschreitet

Analysieren Sie den Grund dafür, dass der betreffende Client die in den Limits definierte zulässige Größe für Anfragen / Nutzlasten überschreitet.
Wenn dies nicht gewünscht ist, ändern Sie Ihre Clientanwendung so, dass sie Anfragen / Nutzlasten sendet, die kleiner als das zulässige Limit sind.

Im oben besprochenen Beispiel können Sie das Problem beheben, indem Sie eine kleinere Datei übergeben, z. B. die Nutzlast test5mbfile (mit einer Größe von 5 MB), wie unten dargestellt:
```
curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
```
Wenn Sie eine Anfrage/Nutzlast senden möchten, die das zulässige Limit überschreitet, fahren Sie mit den nächsten Optionen fort.

Muster für signierte URLs

Option 2 [Empfohlen]: Muster für signierte URLs innerhalb eines Apigee JavaCallouts verwenden

Für Nutzlasten, die größer als 10 MB sind, empfiehlt Apigee, ein Muster für signierte URLs innerhalb eines Apigee JavaCallouts zu verwenden, wie im Beispiel Edge-Callout: Signierte URL-Generator auf GitHub dargestellt.

Streaming

Option 3 : Streaming verwenden

Wenn Ihr API-Proxy sehr große Anfragen und/oder Antworten verarbeiten muss, können Sie Streaming in Apigee aktivieren.

CwC

Option 4 : Pufferlimit mit der CwC-Property erhöhen

Diese Option sollte nur verwendet werden, wenn Sie keine der empfohlenen Optionen nutzen können, da es bei einer Erhöhung der Standardgröße zu Leistungsproblemen kommen kann.

Apigee bietet die CwC-Eigenschaft, mit der das Limit für die Nutzlastgröße von Anfragen und Antworten erhöht werden kann. Weitere Informationen finden Sie unter Größenbeschränkung für Nachrichten im Router oder Message Processor festlegen.

Limits

Apigee erwartet, dass die Clientanwendung und der Backend-Server keine Nutzlastgrößen senden, die das zulässige Limit überschreiten, wie für Request/response size in den Apigee Edge-Limits dokumentiert.

Wenn Sie ein Public Cloud-Nutzer sind, gilt für die maximale Größe der Anfrage- und Antwortnutzlast das Limit, das für Request/response size in den Apigee Edge-Limits dokumentiert ist.
Wenn Sie ein Private Cloud-Nutzer sind, haben Sie möglicherweise das Standardlimit für die Nutzlastgröße von Anfragen und Antworten geändert (auch wenn dies nicht empfohlen wird). Wie Sie das Limit für die maximale Größe der Anfragenutzlast ermitteln, erfahren Sie hier.

Aktuelles Limit prüfen

In diesem Abschnitt wird erläutert, wie Sie prüfen, ob die Property HTTPRequest.body.buffer.limit mit einem neuen Wert in den Message Processors aktualisiert wurde.

Suchen Sie auf dem Message Processor-Computer im Verzeichnis /opt/apigee/edge-message- processor/conf nach dem Attribut HTTPRequest.body.buffer.limit und prüfen Sie mit dem folgenden Befehl, welcher Wert festgelegt wurde:
```
grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
```

Das Beispielergebnis des oben genannten Befehls sieht so aus:

/opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

In der obigen Beispielausgabe sehen Sie, dass die Property HTTPRequest.body.buffer.limit mit dem Wert 10m in http.properties festgelegt wurde.

Das bedeutet, dass das in Apigee for Private Cloud konfigurierte Limit für die Größe der Anfrage-Nutzlast 10 MB beträgt.

Wenn Sie weiterhin Unterstützung vom Apigee-Support benötigen, gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

Erfassen von Diagnoseinformationen erforderlich

Sammeln Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Apigee Edge-Support:

Wenn Sie ein Public Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

Name der Organisation
Name der Umgebung
Name des API-Proxys
Vollständiger curl-Befehl zum Reproduzieren des 413-Fehlers
Trace-Datei für die API-Anfragen

Wenn Sie ein Private Cloud-Nutzer sind, geben Sie die folgenden Informationen an:

Vollständige Fehlermeldung für die fehlgeschlagenen Anfragen
Name der Organisation
Name der Umgebung
API-Proxy-Bundle
Trace-Datei für die fehlgeschlagenen API-Anfragen
Vollständiger curl-Befehl zum Reproduzieren des 413-Fehlers
NGINX-Zugriffslogs /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

Dabei gilt:ORG, ENV und PORT# werden durch tatsächliche Werte ersetzt.
Systemprotokolle des Message Processors /opt/apigee/var/log/edge-message-processor/logs/system.log

413 Anfrageentität zu groß – TooBigBody

Symptom

Fehlermeldung

Mögliche Ursachen

Allgemeine Diagnoseschritte

API-Monitoring

Unkomprimiert

Komprimiert

Trace

Unkomprimiert

Komprimiert

Unkomprimiert

Komprimiert

NGINX

Unkomprimiert

Komprimiert

Ursache: Die Größe der Request-Nutzlast überschreitet das zulässige Limit.

Diagnose

Auflösung

Ursache: Die Größe der Anfragenutzlast überschreitet nach der Dekomprimierung das zulässige Limit.

Diagnose

Trace

Tatsächliche Anfrage

Logs des Message Processors

Auflösung

Größe festlegen

Muster für signierte URLs

Streaming

CwC

Limits

Aktuelles Limit prüfen

Erfassen von Diagnoseinformationen erforderlich