413 Anfrageentität zu groß – TooBigBody

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

Symptom

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

Fehlermeldung

Die Clientanwendung ruft den folgenden Antwortcode ab: 

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, das zulässige Limit in Apigee Edge überschreitet .

Mögliche Ursachen für diesen Fehler sind folgende :

Ursache Beschreibung Anleitungen zur Fehlerbehebung gelten für
Die Größe der Anfragenutzlast überschreitet das zulässige Limit Die Nutzlastgröße, die von der Clientanwendung als Teil einer HTTP-Anfrage an Apigee Edge gesendet wird, überschreitet das zulässige Limit in Apigee Edge. Nutzer von 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 in komprimiertem Format gesendet wird, ist bei Dekomprimierung durch Apigee Edge größer als das zulässige Limit. Nutzer von Edge Public und Private Cloud

Allgemeine Diagnoseschritte

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

API-Monitoring

So diagnostizieren Sie den Fehler mithilfe von API-Monitoring:

  1. Melden Sie sich in der Apigee Edge-UI als Nutzer mit einer entsprechenden Rolle an.

  2. Wechseln Sie zu der Organisation, in der Sie das Problem untersuchen möchten

  3. Rufen Sie die Seite Analysieren > API-Überwachung > Untersuchen auf.
  4. Wählen Sie den Zeitraum aus, in dem Sie die Fehler beobachtet haben.
  5. Sie können den Filter Proxy auswählen, um den Fehlercode einzugrenzen.
  6. Stellen Sie den Fehlercode der Zeit gegenüber.

  7. Wählen Sie wie unten gezeigt eine Zelle aus, die den Fehlercode protocol.http.TooBigBody und den Statuscode 413 enthält:

  8. Informationen zum Fehlercode protocol.http.TooBigBody werden wie unten dargestellt angezeigt:

  9. Klicken Sie auf Logs ansehen und maximieren Sie die Zeile für die fehlgeschlagene Anfrage. Notieren Sie sich dann im Fenster Logs die folgenden Details :

    Unkomprimiert

    Szenario 1: Anfragenutzlast in unkomprimierter Form gesendet

    Beachten Sie im Fenster "Logs" die folgenden Details:

    • Statuscode: 413
    • Fehlerquelle: proxy
    • Fehlercode: protocol.http.TooBigBody.
    • Länge der Anfrage(Byte): 15360440 (~15 MB)

    Wenn die Fehlerquelle den Wert proxy hat , der Fehlercode den Wert protocol.http.TooBigBody und die Anfragelänge mehr als 10 MB beträgt, weist dies darauf hin, dass die HTTP-Anfrage vom Client eine Größe der Anfragennutzlast größer als das zulässige Limit in Apigee hat.

    Komprimiert

    Szenario 2: In komprimierter Form gesendete Anfragenutzlast

    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 hat, der Fehlercode den Wert protocol.http.TooBigBody und die Anfragelänge weniger als 10 MB beträgt, gibt dies an, dass die Nutzlastgröße der HTTP-Anfrage vom Client unter dem zulässigen Grenzwert in komprimiertem Format liegt, die Nutzlastgröße jedoch über dem zulässigen Limit liegt, wenn die Nutzlast nicht von Apigee komprimiert ist.

Trace

So diagnostizieren Sie den Fehler mit dem Trace-Tool:

  1. 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.

  2. Achten Sie darauf, dass Alle Ablaufinformationen anzeigen aktiviert ist.

  3. Wählen Sie eine der fehlgeschlagenen Anfragen aus und prüfen Sie den Trace.
  4. Gehen Sie zur Phase Anfrage vom Client erhalten.

    Unkomprimiert

    Szenario 1: Anfragenutzlast in unkomprimierter Form gesendet

    Beachten Sie die folgenden Informationen:

    • Content-Encoding:nicht vorhanden
    • Content-Length: 15360204

    Komprimiert

    Szenario 2: In komprimierter Form gesendete Anfragenutzlast

    Beachten Sie die folgenden Informationen:

    • Inhaltscodierung: gzip
    • Content-Length: 14969
    • Inhaltstyp: application/x-gzip
  5. Gehen Sie die verschiedenen Phasen des Trace durch und ermitteln Sie, wo der Fehler aufgetreten ist.

  6. Der Fehler tritt normalerweise in einem Ablauf nach der Phase Vom Client erhaltene Anfrage auf, wie unten dargestellt:

  7. Notieren Sie sich den Wert des Fehlers aus dem Trace. Das obige Beispiel-Trace zeigt:
    • Fehler: Body buffer overflow
    • error.class::com.apigee.errors.http.user.RequestTooLarge

  8. Gehen Sie zu Antwort an Client gesendet und notieren Sie sich die Werte des Fehlers aus dem Trace. Der folgende Beispiel-Trace zeigt:

    • Fehler: 413 Request Entity Too Large
    • Fehlerinhalt: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  9. Gehen Sie im Trace zur Phase AX (Analytics Data Recorded) und klicken Sie darauf.

  10. Scrollen Sie im Abschnitt Phasendetails nach unten zu Variablen gelesen.

  11. Ermitteln Sie den Wert der Variablen client.received.content.length . Er gibt Folgendes an:
    • Die tatsächliche Größe der Anfragennutzlast, wenn diese in unkomprimiertem Format gesendet wird.
    • Die Größe der Anfragenutzlast nach der Dekomprimierung durch Apigee, wenn die Nutzlast in komprimiertem Format gesendet wird. Er entspricht in diesem Szenario immer dem zulässigen Limit (10 MB).

    Unkomprimiert

    Szenario 1: Nutzlast in unkomprimierter Form anfordern

    Variable:client.received.content.length: 15360204

    Komprimiert

    Szenario 2: Nutzlast in komprimiertem Format anfordern

    Variable:client.received.content.length: 10489856

  12. In der folgenden Tabelle wird erläutert, warum Apigee in den beiden Szenarien basierend auf dem Wert der client.received.content.length-Variable den Fehler 413 zurückgibt:
    Szenario Wert von client.received.content.length Fehlerursache
    Nutzlast in unkomprimiertem Format anfordern ~15 MB Größe > Maximal 10 MB zulässig.
    Nutzlast in komprimiertem Format anfordern ~10 MB

    Größenbeschränkung bei der Dekomprimierung überschritten

NGINX

So diagnostizieren Sie den Fehler mithilfe von NGINX-Zugriffslogs:

  1. Wenn Sie ein Private Cloud-Nutzer sind, können Sie mithilfe von NGINX-Zugriffslogs die wichtigsten Informationen zu HTTP-413-Fehlern ermitteln.

  2. Prüfen Sie die NGINX-Zugriffslogs:

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

  3. Suchen Sie nach 413-Fehlern innerhalb eines bestimmten Zeitraums (ob das Problem in der Vergangenheit aufgetreten ist) oder ob es immer noch Anfragen mit 413 gibt, die fehlschlagen.
  4. Wenn Sie 413-Fehler mit dem X-Apigee-fault-code finden, der mit dem Wert von X-Apigee-fault-code übereinstimmt, bestimmen Sie den Wert von X-Apigee-fault-code .

    Unkomprimiert

    Szenario 1 : Nutzlastgröße in unkomprimiertem Format anfordern

    Der obige Beispieleintrag aus dem NGINX-Zugriffslog enthält die folgenden Werte für X-Apigee-fault-code und X-Apigee-fault-code :

    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 : Nutzlastgröße in komprimiertem Format anfordern

    Der obige Beispieleintrag aus dem NGINX-Zugriffslog enthält die folgenden Werte für X-Apigee-fault-code und X-Apigee-fault-code :

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

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

    In diesem Szenario gibt Apigee Edge 413 zurück, obwohl die Anfragelänge unter dem zulässigen Grenzwert liegt, da die Anfrage möglicherweise in einem komprimierten Format gesendet wurde und die Größe der Nutzlast bei der Dekomprimierung durch Apigee Edge das Limit überschreitet.

Ursache: Die Nutzlastgröße der Anfrage ist größer als das zulässige Limit

Diagnose

  1. Bestimmen Sie den Fehlercode, die Fehlerquelle und die Größe der Anfragenutzlast für den Fehler, der mithilfe von API-Monitoring, Trace-Tool oder NGINX-Zugriffslogs beobachtet wird, wie unter Allgemeine Diagnoseschritte mit Szenario 1 (unkomprimiert) erläutert.
  2. Wenn die Fehlerquelle den Wert policy oder proxy hat, weist dies darauf hin, dass die von der Clientanwendung an Apigee gesendete Anfragenutzlastgröße das zulässige Limit in Apigee Edge überschreitet.
  3. Prüfen Sie die Größe der Anfragenutzlast wie in Schritt 1 ermittelt.
  4. Sie können auch prüfen, ob die Nutzlastgröße der Anfrage tatsächlich über 10 MB liegt. Das geht so:
    1. Wenn Sie keinen Zugriff auf die eigentliche Anfrage der Clientanwendung haben, wechseln Sie zu Lösung.
    2. Wenn Sie Zugriff auf die eigentliche Anfrage der Clientanwendung haben, führen Sie die folgenden Schritte aus:
      1. Prüfen Sie die Größe der in der Anfrage übergebenen Nutzlast.
      2. Wenn Sie feststellen, dass die Größe der Nutzlast das zulässige Limit in Apigee Edge überschreitet, ist dies die Ursache des Problems.

        3. Beispielanfrage:

        curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v

        Im obigen Fall ist die Datei test15mbfile etwa 15 MB groß. Wenn Sie einen anderen Client verwenden, rufen Sie die Clientlogs ab, um die Größe der gesendeten Nutzlast zu ermitteln.

Auflösung

Gehe zu Lösung.

Ursache: Die Nutzlastgröße der Anfrage überschreitet nach der Dekomprimierung den zulässigen Grenzwert

Wenn die Anfragenutzlast in einem komprimierten Format gesendet wird und der Anfrageheader Content-Encoding auf gzip, gesetzt ist, dekomprimiert Apigee die Anfragenutzlast. Wenn Apigee beim Dekomprimierungsprozess feststellt, dass die Größe der Nutzlast über 10 MB liegt, das zulässige Limit, beendet es die weitere Dekomprimierung und antwortet sofort mit 413 Request Entity Too Large mit dem Fehlercode protocol.http.TooBigBody.

Diagnose

  1. Bestimmen Sie den Fehlercode,die Fehlerquelle und die Größe der Anfragenutzlast für den Fehler,der mithilfe von API-Monitoring, Trace-Tool oder NGINX-Zugriffslogs beobachtet wird, wie unter Allgemeine Diagnoseschritte mit Szenario 2 (komprimiert) erläutert.
  2. Wenn die Fehlerquelle den Wert policy oder proxy hat, weist dies darauf hin, dass die von der Clientanwendung an Apigee gesendete Anforderungsnutzlastgröße das zulässige Limit in Apigee Edge überschreitet.
  3. Prüfen Sie die Größe der Anfragenutzlast (siehe Schritt 1).
    • Wenn die Nutzlastgröße über 10 MB liegt, ist das die Fehlerursache.
    • Wenn die Nutzlastgröße unter 10 MB liegt, kann es sein, dass die Nutzlast der Anfrage in einem komprimierten Format übergeben wird. Prüfen Sie in diesem Fall die unkomprimierte Größe der komprimierten Anfragenutzlast.
  4. Mit einer der folgenden Methoden können Sie prüfen, ob die Anfrage vom Client in einem komprimierten Format gesendet wurde und die nicht komprimierte Größe das zulässige Limit überschreitet:

    Trace

    So validieren Sie mit dem Trace-Tool:

    1. Wenn Sie ein Trace für die fehlgeschlagene Anfrage erfasst haben, folgen Sie den Schritten unter Trace und
      1. Ermitteln Sie den Wert der Variablen client.received.content.length .
      2. Prüfen Sie, ob die Anfrage vom Client den Header Content-Encoding: gzip enthält.
    2. Wenn der Wert der Variablen client.received.content.length größer als 10 MB, das zulässige Limit und der Anfrageheader client.received.content.length ist, ist das die Ursache für diesen Fehler.

    Tatsächliche Anfrage

    So validieren Sie mithilfe der tatsächlichen Anfrage:

    1. Wenn Sie keinen Zugriff auf die eigentliche Anfrage der Clientanwendung haben, wechseln Sie zu Lösung.
    2. Wenn Sie Zugriff auf die eigentliche Anfrage der Clientanwendung haben, führen Sie die folgenden Schritte aus:
      1. Prüfen Sie die Größe der Nutzlast, die in der Anfrage zusammen mit dem in der Anfrage gesendeten Header Content-Encoding übergeben 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 liegt die Datei test15mbfile.gz unter der Größenbeschränkung. Die Größe der unkomprimierten Datei test15mbfile beträgt jedoch ungefähr 15 MB und der Header Content-Encoding ist gzip.

        Wenn Sie einen anderen Client verwenden, rufen Sie die Clientlogs ab, um die gesendete Nutzlastgröße zu ermitteln und festzustellen, ob der Header Content-Encoding auf gzip gesetzt ist.

    Message Processor-Protokolle

    So validieren Sie mithilfe von Message Processor-Protokollen:

    1. Wenn Sie ein Private Cloud-Nutzer sind, können Sie mithilfe von Message Processor-Logs die wichtigsten Informationen zu HTTP-413-Fehlern ermitteln.

    2. Prüfen Sie die Protokolle des Nachrichtenverarbeiters:

      /opt/apigee/var/log/edge-message-processor/logs/system.log

    3. Suchen Sie, ob während eines bestimmten Zeitraums 413-Fehler aufgetreten sind (ob das Problem in der Vergangenheit aufgetreten ist) oder ob es immer noch Anfragen mit 413 gibt, die fehlschlagen.

      Sie können die folgenden Suchzeichenfolgen verwenden:

      grep -ri "chunkCount"

      grep -ri "RequestTooLarge"
    4. Die Zeilen von system.log sehen in etwa so aus (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. Sobald der Message Processor feststellt, dass die Gesamtzahl der gelesenen Byte über 10 MB liegt, wird während der Dekomprimierung die folgende Zeile ausgegeben: 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      Dies impliziert, dass die Größe der Anfragenutzlast größer als 10 MB ist und Apigee den Fehler RequestTooLarge ausgibt, wenn die Größe beginnt, das Limit von 10 MB mit dem Fehlercode protocol.http.TooBigBody zu überschreiten.

Auflösung

Größe korrigieren

Option 1 [empfohlen]: Die Clientanwendung so konfigurieren, dass die Nutzlastgröße das zulässige Limit nicht überschreitet

  1. Analysieren Sie den Grund für das Senden der Anfrage / die Nutzlastgröße für den jeweiligen Client, die das unter Beschränkungen festgelegte Limit überschreitet.

  2. Wenn dies nicht gewünscht ist, ändern Sie Ihre Clientanwendung so, dass sie eine Anfrage-/Nutzlastgröße sendet, die unter dem zulässigen Limit liegt.

    Im oben beschriebenen Beispiel können Sie das Problem beheben, indem Sie eine kleinere Datei, z. B. test5mbfile (mit einer Größe von 5 MB), wie unten gezeigt übergeben: 

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v

  3. Wenn dies gewünscht ist und Sie eine Anfrage/Nutzlast über das zulässige Limit senden möchten, fahren Sie mit den nächsten Optionen fort.

Signiertes URL-Muster

Option 2 [empfohlen]: Muster mit signierten URLs in einem Apigee-JavaCallout verwenden

Für Nutzlasten, die größer als 10 MB sind, empfiehlt Apigee, ein signiertes URL-Muster in einem Apigee JavaCallout zu verwenden, wie im Beispiel Edge Callout: Signed URL Generator auf GitHub veranschaulicht.

Livestreams

Option 3 : Streaming verwenden

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

CwC

Option 4 : CwC-Attribut verwenden, um das Pufferlimit zu erhöhen

Verwenden Sie diese Option nur, wenn Sie keine der empfohlenen Optionen verwenden können, da es zu Leistungsproblemen kommen kann, wenn die Standardgröße erhöht wird.

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

Einschränkungen

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

  1. Wenn Sie ein Public Cloud-Nutzer sind, ist die Obergrenze für die Nutzlastgröße von Anfragen und Antworten unter Request/response size unter Limits für Apigee Edge dokumentiert.
  2. Wenn Sie ein Private Cloud-Nutzer sind, haben Sie möglicherweise das Standardlimit für die Nutzlastgröße von Anfragen und Antworten geändert (obwohl es nicht empfohlen wird). Sie können das Limit für die maximale Nutzlast von Anfragen ermitteln. Folgen Sie dazu der Anleitung unter Aktuelles Limit prüfen.

Wie überprüfe ich das aktuelle Limit?

In diesem Abschnitt wird erläutert, wie Sie überprüfen können, ob die Eigenschaft HTTPRequest.body.buffer.limit mit einem neuen Wert auf den Message Processors aktualisiert wurde.

  1. Suchen Sie auf der Message Processor-Maschine 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
  2. Das Ergebnis des obigen Befehls sieht so aus: 
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

  3. In der obigen Beispielausgabe wurde das Attribut HTTPRequest.body.buffer.limit mit dem Wert 10m in http.properties festgelegt.

    Dies weist darauf hin, dass das Limit für die in Apigee für Private Cloud konfigurierte Größe der Anfragenutzlast 10 MB beträgt.

Wenn Sie weiterhin Unterstützung vom Apigee-Support benötigen, lesen Sie Diagnoseinformationen müssen erfasst werden.

Erfassen von Diagnoseinformationen erforderlich

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

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

  • Name der Organisation
  • Name der Umgebung
  • API-Proxy-Name
  • Schließen Sie den curl-Befehl ab, mit dem der Fehler 413 reproduziert wird
  • Ablaufverfolgungsdatei für die API-Anfragen

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

  • Vollständige Fehlermeldung bei fehlgeschlagenen Anfragen
  • Name der Organisation
  • Name der Umgebung
  • API-Proxy-Bundle
  • Ablaufverfolgungsdatei für fehlgeschlagenen API-Anfragen
  • Schließen Sie den curl-Befehl ab, mit dem der Fehler 413 reproduziert wird

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

    Hierbei gilt: ORG, ENV und PORT# werden durch tatsächliche Werte ersetzt.

  • Systemprotokolle von Message Processor /opt/apigee/var/log/edge-message-processor/logs/system.log