400 Bad Request – DekomprimierenionFailureAtRequest

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

Symptom

Die Clientanwendung erhält den HTTP-Statuscode 400 Bad Request mit dem Fehlercode messaging.adaptors.http.flow.DecompressionFailureAtRequest als Antwort auf API-Aufrufe.

Fehlermeldung

Die Clientanwendung erhält den folgenden Antwortcode:

HTTP/1.1 400 Bad Request

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

{
   "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 Header Content-Encoding der HTTP-Anfrage angegebene Codierung ist gültig und wird von Apigee Edge unterstützt.

ABER

• Das Nutzlastformat, das vom Client als Teil der HTTP-Anfrage gesendet wird, stimmt nicht mit dem im Content-Encoding -Header angegebenen Codierungsformat überein.

Das liegt daran, dass Apigee Edge die Nutzlast nicht mit der angegebenen Codierung decodieren kann, da das Format der Nutzlast nicht mit der im Content-Encoding-Header angegebenen Codierung übereinstimmt.

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

Mögliche Ursachen für diesen Fehler:

Allgemeine Diagnoseschritte

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

Ursache: Das Format der Anfrage-Nutzlast stimmt nicht mit der im Content-Encoding-Header angegebenen Codierung überein.

Standardmäßig dekomprimiert Apigee Edge die Nutzlast immer, wenn der Anfrageheader Content-Encoding eine gültige und unterstützte Codierung enthält. Daher wird erwartet, dass das Format der Anfrage-Nutzlast mit der im Anfrageheader Content-Encoding angegebenen Codierung übereinstimmt. Wenn es eine Abweichung gibt, wird dieser Fehler angezeigt.

Diagnose

1. Ermitteln Sie den Fehlercode und die Fehlerquelle für den beobachteten Fehler mithilfe von API-Monitoring, Trace-Tool oder NGINX-Zugriffsprotokollen, wie in Häufige Diagnoseschritte beschrieben.
2. Wenn der Fehlercode messaging.adaptors.http.flow.DecompressionFailureAtRequest ist und die Fehlerquelle den Wert policy oder proxy hat, bedeutet dies, dass die von der Clientanwendung gesendete Anfrage eine Nutzlast enthält, die nicht mit der im Anfrageheader Content-Encoding angegebenen unterstützten Codierung übereinstimmt.

3. Sie können die Abweichung als Teil der HTTP-Anfrage mit einer der folgenden Methoden ermitteln:

   Fehlermeldung

   So validieren Sie die Inhaberschaft mit der Fehlermeldung:

   1. Wenn Sie Zugriff auf die vollständige Fehlermeldung haben, die Sie von Apigee Edge erhalten haben, lesen Sie die Informationen unter faultstring.

      Beispiel für eine Fehlermeldung:

      "faultstring":"Decompression failure at request"

   2. In der obigen Fehlermeldung wird "Decompression failure at request" angezeigt. Das bedeutet, dass die Anfrage nicht mit der im Header Content-Encoding angegebenen Codierung dekomprimiert werden konnte.

   Trace

   So validieren Sie die Ergebnisse mit Trace:

   1. Ermitteln Sie den Wert des Anfrageheaders Content-Encoding und des Attributs error.cause mit Trace, wie in Häufige Diagnoseschritte beschrieben.

   2. Die Werte aus dem Beispiel-Trace sind:

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

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

   Tatsächliche Anfrage

   So validieren Sie die Anfrage:

   Wenn Sie Zugriff auf die tatsächliche Anfrage der Clientanwendung haben, führen Sie die folgenden Schritte aus:

   1. Ermitteln Sie den Wert, der an den Anfrage-Header Content-Encoding übergeben wird.
   2. Ermitteln Sie das Format der Nutzlast, die als Teil der Anfrage gesendet wird.

   3. Wenn der Wert des Content-Encoding-Headers in der Liste der unterstützten Codierungen enthalten ist, das Format der Anfrage-Nutzlast jedoch nicht mit der im Content-Encoding-Header angegebenen Codierung übereinstimmt, ist dies die Ursache des Problems.

      Beispielanfrage:

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

      In der oben gezeigten Beispielanfrage wird der Wert gzip an den Header Content-Encoding gesendet, der eine unterstützte Codierung in Apigee Edge ist. Die Nutzlast der Anfrage request_payload.zip ist jedoch im ZIP-Format. Daher schlägt diese Anfrage mit dem Statuscode 400 Bad Request und dem Fehlercode messaging.adaptors.http.flow.DecompressionFailureAtRequest fehl.

   Logs des Message Processors

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

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

   1. Ermitteln Sie die Nachrichten-ID der fehlgeschlagenen Anfrage mit API Monitoring, dem Trace-Tool oder NGINX-Zugriffsprotokollen, wie unter Gängige Diagnoseschritte beschrieben.

   2. Suchen Sie im Message Processor-Log 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: API-Anfrage mit dem Header „Content-Encoding: gzip“

      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 Nutzlast der Anfrage nicht im GZIP-Format gesendet wird, obwohl Content-Encoding als gzip angegeben ist. Daher löst Apigee Edge die Ausnahme aus und gibt den Statuscode 400 mit dem Fehlercode messaging.adaptors.http.flow.DecompressionFailureAtRequest an Clientanwendungen zurück.

      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 Zeilen java.util.zip.ZipException: incorrect header check und Caused by: java.util.zip.DataFormatException: incorrect header check in der oben genannten Fehlermeldung weisen darauf hin, dass die Anfrage-Nutzlast nicht im Deflate-Format gesendet wird und nicht mit der im Content-Encoding-Header von Deflate angegebenen Codierung übereinstimmt. Daher löst Apigee Edge die Ausnahme aus und gibt den Statuscode 400 mit dem Fehlercode messaging.adaptors.http.flow.DecompressionFailureAtRequest an Clientanwendungen zurück.

Auflösung

1. Wenn die komprimierte Anfrage-Nutzlast im API-Proxy-Ablauf in Apigee Edge und auf dem Backend-Server nicht benötigt wird, darf der Header Content-Encoding nicht übergeben werden. Wenn die Nutzlast der Anfrage komprimiert werden muss, fahren Sie mit Schritt 2 fort.
2. Achten Sie darauf, dass die Clientanwendung immer Folgendes sendet:
   • Eine der unterstützten Codierungen als Wert für den Content-Encoding-Header in der Anfrage
   • Die Anfrage-Nutzlast im unterstützten Format für Apigee Edge entspricht dem im Content-Encoding-Header angegebenen Codierungsformat.
3. Im oben besprochenen Beispiel ist die Anfrage-Nutzlast im ZIP-Format, im Anfrageheader wird jedoch Content-Encoding: gzip angegeben. Sie können das Problem beheben, indem Sie den Anfrageheader als Content-Encoding: gzip und die Anfrage-Nutzlast ebenfalls im gzip-Format senden:

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

Spezifikation

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

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, der zum Reproduzieren des 400-Fehlers verwendet wurde
• 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 Umgebung
• API-Proxy-Bundle
• Trace-Datei für die API-Anfragen

• 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