400 Bad Request – DekomprimierenionFailureAtRequest

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation.
Weitere Informationen

Symptom

Die Clientanwendung ruft den HTTP-Statuscode 400 Bad Request mit Fehlercode ab messaging.adaptors.http.flow.DecompressionFailureAtRequest als Antwort auf API Anrufe.

Fehlermeldung

Die Clientanwendung ruft den folgenden Antwortcode ab:

HTTP/1.1 400 Bad Request

Außerdem kann eine Fehlermeldung wie die folgende angezeigt werden:

{
   "fault":{
      "faultstring":"Decompression failure at request",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"
      }
   }
}

Mögliche Ursachen

Dieser Fehler tritt nur in folgenden Fällen auf:

  • Die im HTTP-Anfrage-Header Content-Encoding angegebene Codierung ist gültig und <ph type="x-smartling-placeholder"></ph> unterstützt von Apigee Edge,
  • ABER

  • Das Nutzlastformat, das vom Client als Teil der HTTP-Anfrage gesendet wird, Entspricht dem im Header Content-Encoding angegebenen Codierungsformat

Dies liegt daran, dass Apigee Edge die Nutzlast nicht mit der angegebenen Codierung decodieren kann, da die Format der Nutzlast nicht dasselbe Format wie die im Content-Encoding-Header.

<ph type="x-smartling-placeholder">

Hier sind einige Beispiele für unterstützte Content-Encoding-Werte und wie Apigee Edge erwartet in diesen Fällen das Nutzlastformat:

Szenario Content-Encoding Erwartetes Nutzlastformat
Einzelcodierung GZIP

Das Unix-gzip-Format.

Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> RFC 1952-GZIP-Format.

Einzelcodierung entschärfen

Dieses Format verwendet die zlib-Struktur mit dem deflate-Komprimierungsalgorithmus.

Weitere Informationen finden Sie unter . RFC1950 und <ph type="x-smartling-placeholder"></ph> RFC1951.

Mehrfachcodierung

Mehrfachcodierung

Wenn die Codierung zweimal ausgeführt wird, kann dies beispielsweise so aussehen:

  • gzip, deflate
  • gzip, gzip
  • deflate, gzip
  • deflate, deflate, deflate, deflate, deflate, deflate, deflate, deflate
Mehrfachcodierung auf die Nutzlast in der angegebenen Reihenfolge, wie sie im Header angezeigt wird.

Mögliche Ursachen für diesen Fehler:

Ursache Beschreibung Anleitungen zur Fehlerbehebung gelten für
<ph type="x-smartling-placeholder"></ph> Das Nutzlastformat der Anfrage entspricht nicht der Codierung, die im Header „Content-Encoding“ angegeben ist Das Format der vom Client gesendeten Anfragenutzlast ist entweder nicht codiert oder nicht müssen mit der Codierung übereinstimmen, die im Content-Encoding-Header angegeben ist. Edge-Nutzer von öffentlichen und privaten Clouds

Allgemeine Diagnoseschritte

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

API-Monitoring

<ph type="x-smartling-placeholder">

So diagnostizieren Sie den Fehler mithilfe von API-Monitoring:

  1. <ph type="x-smartling-placeholder"></ph> Melden Sie sich in der Apigee Edge-Benutzeroberfläche als Nutzer mit einem Rolle.
  2. Wechseln Sie zu der Organisation, in der Sie das Problem untersuchen möchten.

  3. Wechseln Sie zum Bereich Analysieren > API-Monitoring > Untersuchen.
  4. Wählen Sie den Zeitraum aus, in dem Sie die Fehler beobachtet haben.
  5. Achten Sie darauf, dass der Filter Proxy auf Alle gesetzt ist.
  6. Stellen Sie den Fehlercode in den Vergleich mit der Zeit ein.
  7. Wählen Sie eine Zelle mit dem Fehlercode messaging.adaptors.http.flow.DecompressionFailureAtRequest als (siehe unten):

    ( Größeres Bild ansehen)

  8. Informationen über den Fehlercode messaging.adaptors.http.flow.DecompressionFailureAtRequest wird so angezeigt:

    ( Größeres Bild ansehen)

  9. Klicken Sie auf Logs ansehen und maximieren Sie die Zeile, in der die Fehlermeldung 400 angezeigt wird.

    ( Größeres Bild ansehen)

  10. Im Fenster Logs werden die folgenden Details angezeigt: <ph type="x-smartling-placeholder">
      </ph>
    • Statuscode: 400
    • Fehlerquelle: proxy
    • Fehlercode: messaging.adaptors.http.flow.DecompressionFailureAtRequest.
  11. Wenn die Fehlerquelle den Wert proxy hat, bedeutet dies, dass dass das Nutzlastformat der Anfrage nicht mit dem <ph type="x-smartling-placeholder"></ph> unterstützte Codierung, die im Content-Encoding-Header angegeben ist.

Trace-Tool

<ph type="x-smartling-placeholder">

So diagnostizieren Sie den Fehler mit dem Trace-Tool:

  1. Aktivieren Sie die Trace-Sitzung. und entweder: <ph type="x-smartling-placeholder">
      </ph>
    1. Warten Sie, bis der Fehler 400 Bad Request auftritt, oder
    2. Wenn Sie das Problem reproduzieren können, führen Sie den API-Aufruf aus und reproduzieren Sie 400 Bad Request
  2. Achten Sie darauf, dass Show all FlowInfos (Alle FlowInfos anzeigen) aktiviert ist:

  3. Wählen Sie eine der fehlgeschlagenen Anfragen aus und prüfen Sie den Trace.
  4. Verschiedene Phasen des Trace durchgehen und ermitteln, wo der Fehler auftritt aufgetreten.
  5. Sie finden den Fehler in der Regel in einem Ablauf direkt nach der Request Received from Client wie unten dargestellt:

    ( Größeres Bild ansehen)

  6. Notieren Sie sich die Werte der Eigenschaften aus dem Trace:

    • Fehler: Decompression failure at request
    • error.class: com.apigee.rest.framework.BadRequestException
    • error.cause: Not in GZIP format

    error.cause gibt an, dass die Anfragenutzlast NICHT im GZIP-Format vorliegt. Dies bedeutet, dass Apigee Edge erwartet hat, dass die Anfragenutzlast im GZIP-Format vorliegt wie im Content-Encoding-Header angegeben.

  7. Ermitteln Sie den Wert des Anfrageheaders Content-Encoding. Gehen Sie dazu wie unten dargestellt zur Phase Anfrage vom Client erhalten:

    ( Größeres Bild ansehen)

    Der Wert des Anfrageheaders Content-Encoding ist tatsächlich gzip.

    Das obige Beispiel-Trace zeigt, dass die im Anfrageheader angegebene Codierung Content-Encoding ist gzip; Die Nutzlast der Anfrage nicht im GZIP-Format vorliegt. Daher kann Apigee die Nutzlast nicht mit gzip und gibt den Fehler Decompression failure at request zurück.

  8. Notieren Sie sich den Statuscode und die Fehlermeldung, die von Apigee Edge zurückgegeben werden, indem Sie

    in die Phase Response Sent to Client (An Client gesendet) im Trace übergeben:

    ( Größeres Bild ansehen)

    Achten Sie auf die folgenden Details aus dem Trace:

    • Status code: 400 Bad Request.
    • Fehlerinhalt: {"fault":{"faultstring":"Decompression failure at request","detail":{"errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"}}}
  9. Navigieren Sie im Trace zur Phase AX (Analytics Data Recorded). und klicken Sie darauf.

  10. Scrollen Sie nach unten zum Abschnitt Phase Details, Error Headers und Bestimmen Sie die Werte von X-Apigee-fault-code und X-Apigee-fault-code. wie unten dargestellt:

    ( Größeres Bild ansehen)

  11. Sie sehen die Werte X-Apigee-fault-code und X-Apigee-fault-code. als messaging.adaptors.http.flow.DecompressionFailureAtRequest und policy, was bedeutet, dass das Nutzlastformat der Anfrage nicht mit dem Codierung angegeben, die im Content-Encoding-Header angegeben ist.
    Antwortheader Wert
    X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
    X-Apigee-fault-source policy

NGINX

<ph type="x-smartling-placeholder">

So diagnostizieren Sie den Fehler mithilfe von NGINX-Zugriffslogs:

  1. Als Private Cloud-Nutzer können Sie NGINX-Zugriffslogs für folgende Zwecke verwenden: die wichtigsten Informationen zu HTTP-400-Fehlern ermitteln.
  2. Prüfen Sie die 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.

  3. Suchen, um zu sehen, ob es während eines bestimmten Zeitraums 400 Fehler gibt (wenn das Problem in der Vergangenheit aufgetreten ist) oder wenn immer noch Anfragen mit 400
  4. Wenn Sie 400-Fehler mit dem X-Apigee-fault-code finden entspricht dem Wert von messaging.adaptors.http.flow.DecompressionFailureAtRequest, Bestimmen Sie dann den Wert von X-Apigee-fault-source..

    Beispiel 400-Fehler aus NGINX-Zugriffsprotokoll:

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

    Antwortheader Wert
    X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
    X-Apigee-fault-source policy

Ursache: Das Nutzlastformat der Anfrage entspricht nicht der angegebenen Codierung im Header „Content-Encoding“

Standardmäßig dekomprimiert Apigee Edge die Nutzlast, wenn der Anfrageheader Content-Encoding enthält einen gültigen und einen <ph type="x-smartling-placeholder"></ph> unterstützte Codierung. Daher ist zu erwarten, dass das Format der muss mit der Codierung übereinstimmen, die im Anfrageheader Content-Encoding angegeben ist. Bei einer Abweichung wird dieser Fehler angezeigt.

Diagnose

  1. Ermitteln Sie den Fehlercode und die Fehlerquelle für den mit der API beobachteten Fehler. Monitoring-, Trace-Tool- oder NGINX-Zugriffslogs wie unter Häufige Diagnoseschritte.
  2. Wenn der Fehlercode messaging.adaptors.http.flow.DecompressionFailureAtRequest und die Fehlerquelle den Wert policy oder proxy hat, dann ist dies gibt an, dass die von der Clientanwendung gesendete Anfrage eine Nutzlast aufweist, die nicht mit dem . unterstützte Codierung, die im Anfrageheader Content-Encoding angegeben ist.
  3. Sie können die Abweichung im Rahmen der HTTP-Anfrage mit einer der folgenden Methoden ermitteln: Methoden:

    Fehlermeldung

    So führen Sie eine Validierung mithilfe der Fehlermeldung durch:

    1. Wenn Sie Zugriff auf die vollständige Fehlermeldung von Apigee Edge haben, dann Weitere Informationen finden Sie im faultstring.

      Beispiel für eine Fehlermeldung:

      "faultstring":"Decompression failure at request"
      
    2. In der obigen Fehlermeldung wird "Decompression failure at request", was impliziert, dass die Anfrage konnte nicht mit der in der angegebenen Codierung dekomprimiert werden. Content-Encoding-Header.

    Trace

    So validieren Sie mit Trace:

    1. Bestimmen Sie den Wert des Anfrage-Headers Content-Encoding und den Attribut error.cause mithilfe von Trace wie unter Häufige Diagnoseschritte erläutert.
    2. Die Werte aus dem Beispiel-Trace lauten wie folgt:

      • Content-Encoding: gzip
      • error.cause: Not in GZIP format

      Der Wert im Anfrageheader Content-Encoding lautet gzip. Die Nutzlast der Anfrage liegt jedoch nicht im GZIP-Format vor. (wie durch error.cause angegeben). Daher antwortet Apigee Edge mit 400 Bad Request und Fehlercode messaging.adaptors.http.flow.DecompressionFailureAtRequest.

    Tatsächliche Anfrage

    So validieren Sie die Anfrage anhand der tatsächlichen Anfrage:

    Wenn Sie Zugriff auf die eigentliche Anfrage des Kunden haben Anwendung und führen Sie dann die folgenden Schritte aus:

    1. Ermitteln Sie den Wert, der an den Anfrageheader Content-Encoding übergeben wird.
    2. Bestimmen Sie das Format der Nutzlast, die als Teil der Anfrage gesendet wird.
    3. Wenn der Wert des Headers Content-Encoding in der Liste der <ph type="x-smartling-placeholder"></ph> unterstützte Codierung, aber das Format der Anfragenutzlast mit der im Content-Encoding-Header angegebenen Codierung übereinstimmen, dann ist das die Ursache des Problems.

      Beispielanfrage:

      curl -v "http://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.zip
      

      Bei der Beispielanfrage oben wird der Wert gzip an den Content-Encoding-Header, der eine <ph type="x-smartling-placeholder"></ph> unterstützte Codierung in Apigee Edge. Die Nutzlast der Anfrage request_payload.zip liegt im ZIP-Format vor. Daher wird dieser Antrag schlägt mit dem Statuscode 400 Bad Request und dem Fehlercode fehl: messaging.adaptors.http.flow.DecompressionFailureAtRequest.

    Message Processor-Logs

    <ph type="x-smartling-placeholder">

    So validieren Sie mit Message Processor-Logs:

    Wenn Sie ein Private Cloud-Nutzer sind, können Sie Message Processor-Logs verwenden. um die wichtigsten Informationen zu HTTP-400-Fehlern zu ermitteln.

    1. Bestimmen Sie die Nachrichten-ID der fehlgeschlagenen Anfrage mithilfe des API-Monitorings, des Trace-Tools oder NGINX-Zugriffsprotokolle, wie unter Allgemeine Diagnoseschritte erläutert.
    2. Suchen Sie im Message Processor-Protokoll nach der Nachrichten-ID:

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

    3. Es wird eine der folgenden Ausnahmen angezeigt:

      Szenario 1

      Szenario 1: Wenn die API-Anfrage den Header „Content-Encoding: gzip“ enthält

      2021-07-28 10:21:16,861  NIOThread@0 ERROR HTTP.SERVER -
      HTTPServer$Context.onInputException() : Message id:rt-57-1
      SSLClientChannel[Accepted: Remote:192.168.199.8:8443
      Local:192.168.80.234:44284]@28469 useCount=1 bytesRead=0
      bytesWritten=28764 age=2739893ms  lastIO=0ms
      isOpen=true.onExceptionRead exception: {}
      java.util.zip.ZipException: Not in GZIP format
      
      2021-07-28 10:21:16,862  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW -
      AbstractRequestListener.onException() : Request:POST, uri:/test,
      message Id:rt-57-1, exception:java.util.zip.ZipException: Not in GZIP format,
      context:Context@71ea5ac input=ClientInputChannel(SSLClientChannel[Accepted:
      Remote:192.168.199.8:8443 Local:192.168.80.234:44284]@28469 useCount=1
      bytesRead=0 bytesWritten=28764 age=2739894ms  lastIO=0ms  isOpen=true)
      2021-07-28 10:21:16,862  NIOThread@0 INFO  HTTP.SERVICE -
      ExceptionHandler.handleException() :
      Exception java.util.zip.ZipException: Not in GZIP format occurred while writing
      to channel null
      2021-07-28 10:21:16,863  NIOThread@0 INFO  HTTP.SERVICE -
      ExceptionHandler.handleException() : Exception trace:
      java.util.zip.ZipException: Not in GZIP format
      

      Die Zeile java.util.zip.ZipException: Not in GZIP format in der obigen Fehlermeldung gibt an, dass die Anfrage wird nicht im GZIP-Format gesendet, obwohl die Content-Encoding als gzip angegeben. Daher wirft Apigee Edge die Ausnahme und gibt einen 400-Statuscode mit Fehlercode zurück messaging.adaptors.http.flow.DecompressionFailureAtRequest Client-Anwendungen.

      Szenario 2

      Szenario 2: Wenn die API-Anfrage den Header „Content-Encoding: deflate“ enthält

      2021-07-28 15:26:31,893  NIOThread@1 ERROR HTTP.SERVER -
      HTTPServer$Context.onInputException() : Message id:rt-47875-1
      SSLClientChannel[Accepted: Remote:192.168.199.8:8443
      Local:192.168.81.72:45954]@29276 useCount=1 bytesRead=0
      bytesWritten=37230 age=3498856ms  lastIO=1ms
      isOpen=true.onExceptionRead exception: {}
      java.util.zip.ZipException: incorrect header check
                        ….
      Caused by: java.util.zip.DataFormatException: incorrect header check
             ..
      2021-07-28 15:26:31,894  NIOThread@1 ERROR ADAPTORS.HTTP.FLOW -
      AbstractRequestListener.onException() : Request:POST, uri:/test,
      message Id:rrt-47875-1, exception:java.util.zip.ZipException:
      incorrect header check, context:Context@69b3ac45
      input=ClientInputChannel(SSLClientChannel[Accepted:
      Remote:192.168.199.8:8443 Local:192.168.81.72:45954]@29276
      useCount=1 byt	esRead=0 bytesWritten=37230 age=3498856ms
      lastIO=1ms  isOpen=true)
      

      Die Linien java.util.zip.ZipException: incorrect header check und Caused by: java.util.zip.DataFormatException: incorrect header check in der obigen Fehlermeldung darauf hinweisen, dass die Anfragenutzlast nicht im deflate-Format und entspricht nicht der im Content-Encoding-Header von deflate. Daher wird Apigee Edge löst die Ausnahme aus und gibt den Statuscode 400 mit Fehlercode messaging.adaptors.http.flow.DecompressionFailureAtRequest Client-Anwendungen.

Auflösung

  1. Wenn die komprimierte Anfragenutzlast im API-Proxy-Ablauf in Apigee Edge nicht benötigt wird und im Back-End-Server, dann übergeben Sie nicht den Header Content-Encoding. Wenn die Anforderungsnutzlast komprimiert werden muss, fahren Sie mit Schritt 2 fort.
  2. Die Clientanwendung muss immer Folgendes senden: <ph type="x-smartling-placeholder">
      </ph>
    • Alle <ph type="x-smartling-placeholder"></ph> unterstützte Codierung als Wert für den Content-Encoding-Header in der Anfrage
    • Die Anfragenutzlast im unterstützten Format an Apigee Edge entspricht der Codierung Format im Content-Encoding-Header angegeben
  3. Im oben erläuterten Beispiel liegt die Anfragenutzlast im ZIP-Format vor, aber der Anfrageheader gibt Content-Encoding: gzip an. Sie können das Problem beheben, indem Sie die Anfrage senden als Content-Encoding: gzip und die Nutzlast der Anfrage auch in gzip. Format:
    curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.gz
    
    <ph type="x-smartling-placeholder">

Spezifikation

Apigee Edge antwortet mit dem Statuscode 400 Bad Request und dem Fehlercode messaging.adaptors.http.flow.DecompressionFailureAtRequest gemäß folgenden RFC Spezifikationen:

Spezifikation
<ph type="x-smartling-placeholder"></ph> RFC 7231, Abschnitt 6.5.1
<ph type="x-smartling-placeholder"></ph> RFC 7231, Abschnitt 3.1.2.2

Wenn Sie weitere Unterstützung vom Apigee-Support benötigen, rufen Sie auf. Diagnosedaten 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
  • Vollständiger curl-Befehl zum Reproduzieren des 400-Fehlers
  • Ablaufverfolgungsdatei für API-Anfragen

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

  • Vollständige Fehlermeldung für fehlgeschlagene Anfragen
  • Name der Umgebung
  • API-Proxy-Bundle
  • Ablaufverfolgungsdatei für API-Anfragen
  • NGINX-Zugriffslogs /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

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

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