<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, - Das Nutzlastformat, das vom Client als Teil der HTTP-Anfrage gesendet wird,
Entspricht dem im Header
Content-Encoding
angegebenen Codierungsformat
ABER
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.
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- Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> RFC 1952-GZIP-Format. |
Einzelcodierung | entschärfen | Dieses Format verwendet die 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:
|
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:
- <ph type="x-smartling-placeholder"></ph> Melden Sie sich in der Apigee Edge-Benutzeroberfläche als Nutzer mit einem Rolle.
Wechseln Sie zu der Organisation, in der Sie das Problem untersuchen möchten.
- Wechseln Sie zum Bereich Analysieren > API-Monitoring > Untersuchen.
- Wählen Sie den Zeitraum aus, in dem Sie die Fehler beobachtet haben.
- Achten Sie darauf, dass der Filter Proxy auf Alle gesetzt ist.
- Stellen Sie den Fehlercode in den Vergleich mit der Zeit ein.
Wählen Sie eine Zelle mit dem Fehlercode
messaging.adaptors.http.flow.DecompressionFailureAtRequest
als (siehe unten):Informationen über den Fehlercode
messaging.adaptors.http.flow.DecompressionFailureAtRequest
wird so angezeigt:Klicken Sie auf Logs ansehen und maximieren Sie die Zeile, in der die Fehlermeldung
400
angezeigt wird.- Im Fenster Logs werden die folgenden Details angezeigt:
<ph type="x-smartling-placeholder">
- </ph>
- Statuscode:
400
- Fehlerquelle:
proxy
- Fehlercode:
messaging.adaptors.http.flow.DecompressionFailureAtRequest
.
- Statuscode:
- 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 imContent-Encoding
-Header angegeben ist.
Trace-Tool
<ph type="x-smartling-placeholder">So diagnostizieren Sie den Fehler mit dem Trace-Tool:
- Aktivieren Sie die Trace-Sitzung.
und entweder:
<ph type="x-smartling-placeholder">
- </ph>
- Warten Sie, bis der Fehler
400 Bad Request
auftritt, oder - Wenn Sie das Problem reproduzieren können, führen Sie den API-Aufruf aus und reproduzieren Sie
400 Bad Request
- Warten Sie, bis der Fehler
Achten Sie darauf, dass Show all FlowInfos (Alle FlowInfos anzeigen) aktiviert ist:
- Wählen Sie eine der fehlgeschlagenen Anfragen aus und prüfen Sie den Trace.
- Verschiedene Phasen des Trace durchgehen und ermitteln, wo der Fehler auftritt aufgetreten.
Sie finden den Fehler in der Regel in einem Ablauf direkt nach der Request Received from Client wie unten dargestellt:
-
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. - Fehler:
Ermitteln Sie den Wert des Anfrageheaders
Content-Encoding
. Gehen Sie dazu wie unten dargestellt zur Phase Anfrage vom Client erhalten:Der Wert des Anfrageheaders
Content-Encoding
ist tatsächlichgzip
.Das obige Beispiel-Trace zeigt, dass die im Anfrageheader angegebene Codierung
Content-Encoding
istgzip
; Die Nutzlast der Anfrage nicht im GZIP-Format vorliegt. Daher kann Apigee die Nutzlast nicht mit gzip und gibt den FehlerDecompression failure at request
zurück.- 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:
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"}}}
- Status code:
Navigieren Sie im Trace zur Phase AX (Analytics Data Recorded). und klicken Sie darauf.
- 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:
- Sie sehen die Werte X-Apigee-fault-code und X-Apigee-fault-code.
als
messaging.adaptors.http.flow.DecompressionFailureAtRequest
undpolicy
, was bedeutet, dass das Nutzlastformat der Anfrage nicht mit dem Codierung angegeben, die imContent-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:
- Als Private Cloud-Nutzer können Sie NGINX-Zugriffslogs für folgende Zwecke verwenden:
die wichtigsten Informationen zu HTTP-
400
-Fehlern ermitteln. 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.
- 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 mit400
Wenn Sie
400
-Fehler mit dem X-Apigee-fault-code finden entspricht dem Wert vonmessaging.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
- 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.
- Wenn der Fehlercode
messaging.adaptors.http.flow.DecompressionFailureAtRequest
und die Fehlerquelle den Wertpolicy
oderproxy
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 AnfrageheaderContent-Encoding
angegeben ist. 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:
-
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"
- 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:
- Bestimmen Sie den Wert des Anfrage-Headers Content-Encoding und den Attribut error.cause mithilfe von Trace wie unter Häufige Diagnoseschritte erläutert.
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 Fehlercodemessaging.adaptors.http.flow.DecompressionFailureAtRequest
.- Content-Encoding:
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:
- Ermitteln Sie den Wert, der an den Anfrageheader
Content-Encoding
übergeben wird. - Bestimmen Sie das Format der Nutzlast, die als Teil der Anfrage gesendet wird.
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 imContent-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.zipBei der Beispielanfrage oben wird der Wert
gzip
an denContent-Encoding
-Header, der eine <ph type="x-smartling-placeholder"></ph> unterstützte Codierung in Apigee Edge. Die Nutzlast der Anfragerequest_payload.zip
liegt im ZIP-Format vor. Daher wird dieser Antrag schlägt mit dem Statuscode400 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.- Bestimmen Sie die Nachrichten-ID der fehlgeschlagenen Anfrage mithilfe des API-Monitorings, des Trace-Tools oder NGINX-Zugriffsprotokolle, wie unter Allgemeine Diagnoseschritte erläutert.
Suchen Sie im Message Processor-Protokoll nach der Nachrichten-ID:
/opt/apigee/var/log/edge-message-processor/logs/system.log
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 formatDie 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 dieContent-Encoding
als gzip angegeben. Daher wirft Apigee Edge die Ausnahme und gibt einen400
-Statuscode mit Fehlercode zurückmessaging.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
undCaused 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 imContent-Encoding
-Header von deflate. Daher wird Apigee Edge löst die Ausnahme aus und gibt den Statuscode400
mit Fehlercodemessaging.adaptors.http.flow.DecompressionFailureAtRequest
Client-Anwendungen.
-
Auflösung
- 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. - 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
- Alle
<ph type="x-smartling-placeholder"></ph>
unterstützte Codierung als Wert für den
- 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 alsContent-Encoding: gzip
und die Nutzlast der Anfrage auch ingzip
. 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 des400
-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