400 Bad Request – DekomprimierenionFailureAtRequest

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 400 Bad Request mit dem Fehlercode messaging.adaptors.http.flow.DecompressionFailureAtRequest .

Fehlermeldung

Die Clientanwendung ruft den folgenden Antwortcode ab:

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

ABER

• Das vom Client als Teil der HTTP-Anfrage gesendete Nutzlastformat entspricht nicht dem Codierungsformat, das im Content-Encoding -Header angegeben ist.

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

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

Szenario	Content-Encoding	Erwartetes Nutzlastformat
Einzelcodierung	gzip	Das Unix-Format gzip. Siehe RFC1952 GZIP-Format.
Einzelcodierung	Deflate	Dieses Format verwendet die zlib-Struktur mit Deflate-Komprimierungsalgorithmus. Siehe RFC1950 und RFC1951.
Mehrfachcodierung	Mehrfachcodierung Wird die Codierung beispielsweise zweimal durchgeführt, kann das so aussehen: gzip, deflate GZIP, GZIP deflate, gzip verkleinern	Mehrfachcodierung, die in der im Header angegebenen Reihenfolge auf die Nutzlast angewendet wird.

Mögliche Ursachen für diesen Fehler:

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Das Format der Anfragenutzlast stimmt nicht mit der im Header „Content-Encoding“ angegebenen Codierung überein	Das Format der vom Client gesendeten Anfragenutzlast ist entweder nicht codiert oder stimmt nicht mit der im Header Content-Encoding angegebenen Codierung überein.	Nutzer von Edge Public und Private Cloud

Allgemeine Diagnoseschritte

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

Ursache: Das Format der Nutzlast der Anfrage 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 sollte das Format der Anfragenutzlast mit der Codierung übereinstimmen, die im Anfrageheader Content-Encoding angegeben ist. Wenn es eine Abweichung gibt, wird diese Fehlermeldung angezeigt.

Diagnose

1. Bestimmen Sie den Fehlercode und die Fehlerquelle für den beobachteten Fehler mithilfe von API-Monitoring, Trace-Tool oder NGINX-Zugriffslogs, wie unter Allgemeine Diagnoseschritte erläutert.
2. Wenn der Fehlercode messaging.adaptors.http.flow.DecompressionFailureAtRequest ist und die Fehlerquelle den Wert policy oder proxy hat, weist dies darauf hin, dass die von der Clientanwendung gesendete Anfrage eine Nutzlast hat, die nicht mit der unterstützten Codierung übereinstimmt, die im Anfrageheader Content-Encoding angegeben ist.

3. Du kannst die Abweichung als Teil der HTTP-Anfrage mit einer der folgenden Methoden ermitteln:

   Fehlermeldung

   So validieren Sie mithilfe der Fehlermeldung:

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

      Beispiel für eine Fehlermeldung:

      "faultstring":"Decompression failure at request"
      

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

   Trace

   So validieren Sie mit dem Trace:

   1. Ermitteln Sie den Wert des Anfrageheaders Content-Encoding und des Attributs error.cause mithilfe von Trace, wie unter Allgemeine Diagnoseschritte erläutert.

   2. Die Werte aus dem Beispiel-Trace lauten wie folgt:

      • Inhaltscodierung: gzip
      • error.cause::Not in GZIP format

      Der Wert im Anfrageheader Content-Encoding ist gzip. Die Nutzlast der Anfrage hat jedoch nicht das 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 mithilfe der tatsächlichen Anfrage:

   Wenn Sie Zugriff auf die eigentliche Anfrage der Clientanwendung haben, führen Sie 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 unterstützten Codierung enthalten ist, das Format der Anfragenutzlast jedoch nicht mit der im Content-Encoding-Header angegebenen Codierung übereinstimmt, ist das die Ursache des Problems.

      Beispielanfrage:

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

      Die obige Beispielanfrage sendet den Wert gzip an den Header Content-Encoding, bei dem es sich um eine unterstützte Codierung in Apigee Edge handelt. Die Anfragennutzlast request_payload.zip liegt jedoch im ZIP-Format vor. Daher schlägt diese Anfrage mit dem Statuscode 400 Bad Request und dem Fehlercode messaging.adaptors.http.flow.DecompressionFailureAtRequest fehl.

   Message Processor-Protokolle

   So validieren Sie mithilfe von Message Processor-Protokollen:

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

   1. Bestimmen Sie die Nachrichten-ID der fehlgeschlagenen Anfrage mithilfe von API-Monitoring, Trace-Tool oder NGINX-Zugriffslogs, 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. Sie sehen eine der folgenden Ausnahmen:

      Szenario 1

      Szenario 1: Wenn die API-Anfrage den Header „Content-Encoding: gzip“ hat

      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 gibt 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“ hat

      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 obigen Fehlermeldung geben an, dass die Nutzlast der Anfrage nicht im Deflate-Format gesendet wird und nicht mit der Codierung übereinstimmt, die im Content-Encoding-Header von Deflate angegeben ist. Daher gibt 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 Anfragenutzlast im API-Proxy-Ablauf in Apigee Edge und auf dem Back-End-Server nicht benötigt wird, übergeben Sie den Header Content-Encoding nicht. 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 Anfragenutzlast im unterstützten Format an Apigee Edge stimmt mit dem im Content-Encoding-Header angegebenen Codierungsformat überein.
3. Im oben beschriebenen Beispiel liegt die Anfragenutzlast im ZIP-Format vor, aber der Anfrageheader gibt Content-Encoding: gzip an. Sie können das Problem beheben, indem Sie den Anfrageheader als Content-Encoding: gzip und die Anfragenutzlast auch im Format gzip senden:

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

Spezifikation

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

Spezifikation
RFC 7231, Abschnitt 6.5.1
RFC 7231, Abschnitt 3.1.2.2

Wenn Sie weiterhin Unterstützung vom Apigee-Support benötigen, lesen Sie Diagnoseinformationen müssen eingeholt 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
• Führen Sie den Befehl curl aus, mit dem der Fehler 400 reproduziert wurde
• 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 Umgebung
• API-Proxy-Bundle
• Ablaufverfolgungsdatei für die API-Anfragen

• 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