Vous consultez la documentation d'Apigee Edge.
Consultez la
documentation Apigee X. en savoir plus
Problème constaté
L'application cliente obtient un code d'état HTTP 502 Bad Gateway
avec le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtResponse
en réponse à des appels d'API.
Message d'erreur
L'application cliente reçoit le code de réponse suivant:
HTTP/1.1 502 Bad Gateway
En outre, un message d'erreur semblable à celui présenté ci-dessous peut s'afficher:
{ "fault":{ "faultstring":"Decompression failure at response", "detail":{ "errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtResponse" } } }
Causes possibles
Cette erreur ne se produit que dans les cas suivants :
- L'encodage spécifié dans l'en-tête de réponse HTTP (à partir du serveur backend/cible)
Content-Encoding
est valide et compatible avec Apigee Edge. - Le format de la charge utile envoyé par le serveur backend/cible dans le cadre de la réponse HTTP ne correspond pas au format d'encodage spécifié dans l'en-tête
Content-Encoding
.
MAIS
En effet, Apigee Edge ne parvient pas à décoder la charge utile à l'aide de l'encodage spécifié, car le format de la charge utile n'est pas au même format que celui spécifié dans l'en-tête Content-Encoding
.
Voici quelques exemples de valeurs Content-Encoding
acceptées et la manière dont Apigee Edge s'attend à ce que la représentation de la charge utile soit dans ces cas:
Scénario | Content-Encoding | Représentation de la charge utile |
---|---|---|
Encodage unique | gzip | Format Unix Consultez la section Format GZIP RFC1952. |
Encodage unique | dégonfler | Ce format utilise une structure |
Encodage multiple | Encodage multiple Par exemple, si l'encodage est effectué deux fois, voici les possibilités qui s'offrent à vous:
|
Encodage multiple appliqué à la charge utile dans l'ordre donné, tel qu'il apparaît dans l'en-tête. |
Causes possibles de cette erreur:
Cause | Description | Instructions de dépannage applicables |
---|---|---|
Le format de la charge utile de la réponse ne correspond pas à Content-Encoding | Le format de la charge utile de réponse envoyée par le serveur backend/cible n'est pas encodé ou ne correspond pas à l'encodage spécifié dans l'en-tête Content-Encoding . |
Utilisateurs Edge Public and Private Cloud |
Étapes de diagnostic courantes
Utilisez l'un des outils ou techniques suivants pour diagnostiquer cette erreur:
Surveillance des API
Pour diagnostiquer l'erreur à l'aide de la surveillance des API:
- Connectez-vous à l'interface utilisateur Apigee Edge en tant qu'utilisateur disposant du rôle approprié.
Accédez à l'organisation dans laquelle vous souhaitez examiner le problème.
- Accédez à la page Analyze > API Monitoring > Investigate (Analyser > Surveillance des API > Enquêter).
- Sélectionnez la période spécifique au cours de laquelle vous avez observé les erreurs.
- Assurez-vous que le filtre Proxy est défini sur Tous.
- Tracez le code d'erreur par rapport à l'heure.
Sélectionnez une cellule avec le code d'erreur
messaging.adaptors.http.flow.DecompressionFailureAtResponse
, comme indiqué ci-dessous:Les informations sur le code d'erreur
messaging.adaptors.http.flow.DecompressionFailureAtResponse
s'affichent comme indiqué ci-dessous:Cliquez sur Afficher les journaux, puis développez la ligne en échec avec l'erreur
502
.- Dans la fenêtre Journaux, notez les détails suivants :
- Code d'état:
502
- Source de l'erreur:
target
- Code d'erreur:
messaging.adaptors.http.flow.DecompressionFailureAtResponse
.
- Code d'état:
- Si la valeur de Fault Source est
target
, cela signifie que le format de charge utile de la réponse ne correspond pas à l' encodage compatible spécifié dans l'en-tête de réponseContent-Encoding
du serveur backend.
Outil de traçage
Pour diagnostiquer l'erreur à l'aide de l'outil Trace:
- Activez la session de trace, puis effectuez l'une des opérations suivantes :
- Attendez que l'erreur
502 Bad Gateway
se produise. - Si vous pouvez reproduire le problème, effectuez l'appel d'API et reproduisez
502 Bad Gateway
.
- Attendez que l'erreur
Assurez-vous que l'option Show all FlowInfos (Afficher tous les FlowInfos) est activée:
- Sélectionnez l'une des réponses ayant échoué et examinez la trace.
- Parcourez les différentes phases de la trace et localisez l'origine de l'échec.
Vous trouverez généralement l'erreur dans un flux juste après la phase Réponse reçue du serveur cible, comme indiqué ci-dessous:
-
Notez les valeurs des propriétés à partir de la trace:
- Content-Encoding:
gzip
- Corps du contenu de la réponse:
{"fault":{"faultstring":"Decompression failure at response","detail":{"errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtResponse"}}}
- Content-Encoding:
Accédez à la phase d'erreur juste après la phase Réponse reçue du serveur cible:
( Afficher l'image plus grande)
Notez les propriétés:
- erreur:
Decompression failure at response
- error.class::
com.apigee.errors.http.server.BadGateway
error.cause::
Not in GZIP format
error.cause indique que la charge utile de la réponse n'est pas au format GZIP. Cela signifie qu'Apigee Edge s'attendait à ce que la charge utile de la réponse soit au format GZIP, comme indiqué dans l'en-tête
Content-Encoding
(déterminé à l'étape précédente).Par conséquent, Apigee Edge ne peut pas décompresser la charge utile à l'aide de gzip et renvoie l'erreurDecompression failure at response
.
Notez que, dans ce cas, la réponse du serveur cible/backend est
200
. Cependant, l'application cliente recevra une réponse502
, car Apigee Edge renvoie l'erreur.- erreur:
Accédez à la phase Response Sent to Client (Réponse envoyée au client) dans la trace, puis cliquez dessus.
( Afficher l'image plus grande)
Notez les informations suivantes à partir de la trace:
- Code d'état:
502 Bad Gateway
. - Contenu de l'erreur:
{"fault":{"faultstring":"Decompression failure at response","detail":{"errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtResponse"}}}
- Code d'état:
Accédez à la phase AX (Données analytiques enregistrées) dans la trace et cliquez dessus.
- Faites défiler la page jusqu'à Détails de la phase, section En-têtes d'erreur et déterminez les valeurs de X-Apigee-fault-code et X-Apigee-fault-source, comme indiqué ci-dessous:
- Vous verrez les valeurs de X-Apigee-fault-code et X-Apigee-fault-source comme
messaging.adaptors.http.flow.DecompressionFailureAtResponse
ettarget
, ce qui indique que le format de la charge utile de la réponse ne correspondait pas à l'encodage spécifié dans l'en-têteContent-Encoding
.En-têtes de réponse Valeur X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtResponse
X-Apigee-fault-source target
NGINX
Pour diagnostiquer l'erreur à l'aide des journaux d'accès NGINX, procédez comme suit:
- Si vous êtes un utilisateur du cloud privé, vous pouvez utiliser les journaux d'accès NGINX pour déterminer les informations essentielles sur les erreurs HTTP
502
. Vérifiez les journaux d'accès NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Où:ORG, ENV et PORT# sont remplacés par des valeurs réelles.
- Recherchez s'il existe des erreurs
502
pendant une durée spécifique (si le problème s'est déjà produit par le passé) ou si des réponses échouent toujours avec502
. Si vous trouvez des erreurs
502
avec le X-Apigee-fault-code correspondant à la valeur demessaging.adaptors.http.flow.DecompressionFailureAtResponse
, déterminez la valeur de X-Apigee-fault-codeExemple d'erreur 502 du journal d'accès NGINX:
L'exemple d'entrée ci-dessus du journal d'accès NGINX contient les valeurs suivantes pour X-Apigee-fault-code et X-Apigee-fault-code :
En-têtes de réponse Valeur X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtResponse
X-Apigee-fault-source target
Cause: le format de la charge utile de la réponse ne correspond pas à Content-Encoding
Par défaut, Apigee Edge décompresse toujours la charge utile si l'en-tête de réponse Content-Encoding
contient un
encodage compatible valide. Par conséquent, il est normal que le format de la charge utile de réponse correspond à l'encodage spécifié dans l'en-tête de réponse Content-Encoding
.
Si ce n'est pas le cas, ce message d'erreur s'affiche.
Diagnostic
- Déterminez le code d'erreur et la source de l'erreur de l'erreur observée à l'aide de la surveillance des API, de l'outil Trace ou des journaux d'accès NGINX, comme expliqué dans la section Étapes de diagnostic courantes.
- Si le code d'erreur est
messaging.adaptors.http.flow.DecompressionFailureAtResponse
et que la source d'erreur a la valeurtarget
, cela indique que le format de la charge utile de réponse envoyée par le serveur backend/cible ne correspond pas à l' encodage compatible spécifié dans l'en-tête de réponseContent-Encoding
. Vous pouvez déterminer la non-concordance dans la réponse HTTP en utilisant l'une des méthodes suivantes:
Message d'erreur
Pour valider à l'aide du message d'erreur:
-
Si vous avez accès au message d'erreur complet reçu d'Apigee Edge, reportez-vous au
faultstring
.Exemple de message d'erreur:
"faultstring":"Decompression failure at response"
- Dans le message d'erreur ci-dessus,
"Decompression failure at response"
s'affiche, ce qui implique que la réponse n'a pas pu être décompressée à l'aide de l'encodage spécifié dans l'en-têteContent-Encoding
.
Trace
Pour valider à l'aide de Trace:
- Déterminez les valeurs Content-Type et error.cause à l'aide de Trace, comme expliqué dans la section Étapes de diagnostic courantes.
Les valeurs de l'exemple de trace sont les suivantes:
- Content-Encoding:
gzip
- error.cause::
Not in GZIP format
La valeur de l'en-tête de réponse Content-Encoding est gzip. Cependant, la charge utile de la réponse n'est pas au format GZIP (comme indiqué par error.cause). Par conséquent, Apigee Edge répond avec
502 Bad Gateway
et le code d'erreurmessaging.adaptors.http.flow.DecompressionFailureAtResponse
.- Content-Encoding:
Demande réelle
Pour valider à l'aide de la requête réelle:
Si vous avez accès à la requête réelle envoyée à l'application du serveur cible/backend, procédez comme suit:
- Si vous êtes un utilisateur de cloud public/cloud privé, envoyez une requête directement au serveur backend à partir du serveur backend lui-même ou de toute autre machine à partir de laquelle vous êtes autorisé à envoyer la requête au serveur backend.
- Si vous êtes un utilisateur du cloud privé, vous pouvez également envoyer la requête au serveur backend à partir de l'un des processeurs de messages.
- Examiner la réponse envoyée par le serveur backend et déterminer la valeur transmise dans l'en-tête de réponse
Content-Encoding.
- Déterminez le format de la charge utile envoyée dans le cadre de la requête.
- Si la valeur de l'en-tête
Content-Encoding
figure dans la liste des encodages compatibles, mais que le format de la charge utile de la réponse ne correspond pas à l'encodage spécifié dans l'en-têteContent-Encoding
, c'est la cause du problème.Exemple:
curl -v https://HOSTALIAS/test
***trimmed*** > < HTTP/1.1 200 OK < Accept-Ranges: bytes <
Content-Encoding: gzip
< Date: Mon, 02 Aug 2021 08:17:35 GMT < Transfer-Encoding: chunked < < response_payload.zip Response Body(not in GZIP format)>L'exemple de réponse ci-dessus envoie la valeur
gzip
à l'en-têteContent-Encoding
, qui est un encodage compatible dans Apigee Edge. Cependant, leresponse_payload.zip
est envoyé sous forme de fichier ZIP. Par conséquent, cette réponse échoue avec une erreur502 Bad Gateway
avec le code d'erreur suivant :messaging.adaptors.http.flow.DecompressionFailureAtResponse
.
Journaux du processeur de messages
Pour valider à l'aide des journaux du processeur de messages:
Si vous êtes un utilisateur du cloud privé, vous pouvez utiliser les journaux du processeur de messages pour déterminer les informations clés sur les erreurs HTTP
502
.Consultez le journal du processeur de messages:
/opt/apigee/var/log/edge-message-processor/logs/system.log
Recherchez s'il existe des erreurs
502
pendant une durée spécifique (si le problème s'est déjà produit par le passé) ou si des réponses échouent toujours avec502
. Vous pouvez utiliser la chaîne de recherche suivante:grep -ri "ZipException"
Vous trouverez des lignes du fichier system.log semblables à ce qui suit:
Scénario 1
Scénario 1: lorsque la réponse de l'API comporte l'en-tête Content-Encoding: gzip
2021-08-02 06:50:25,433 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onInputException() : ClientInputChannel(ClientChannel[Connected: Remote:3.8.1.1:9000 Local:10.0.115.32:41298]@38140 useCount=1 bytesRead=0 bytesWritten=203 age=469ms lastIO=0ms isOpen=true).onExceptionRead exception: {}
java.util.zip.ZipException: Not in GZIP format
---trimmed-- 2021-08-02 06:50:25,433 NIOThread@2 INFO HTTP.CLIENT - HTTPClient$Context.logContextDetails() : Request details : host=null path=/folder/testFile method=GET. Channel details : Bytes read=0 2021-08-02 06:50:25,434 NIOThread@2 ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() : AbstractResponseListener.onError(HTTPResponse@4806fdab, Not in GZIP format) 2021-08-02 06:50:25,434 NIOThread@2 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exceptionjava.util.zip.ZipException: Not in GZIP format
occurred while writing to channel null 2021-08-02 06:50:25,434 NIOThread@2 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace: java.util.zip.ZipException: Not in GZIP formatLa ligne
java.util.zip.ZipException: Not in GZIP format
dans le message d'erreur ci-dessus indique que la charge utile de la réponse n'est pas envoyée au format GZIP alors queContent-Encoding
est spécifié comme gzip. Par conséquent, Apigee Edge génère l'exception et renvoie un code d'état502
avec le code d'erreurmessaging.adaptors.http.flow.DecompressionFailureAtResponse
aux applications clientes.Scénario 2
Scénario 2: lorsque la réponse de l'API comporte l'en-tête Content-Encoding: deflate
2021-08-02 06:35:21,215 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onInputException() : ClientInputChannel(ClientChannel[Connected: Remote:3.8.1.1:9000 Local:192.168.194.140:35224]@36014 useCount=1 bytesRead=0 bytesWritten=202 age=439ms lastIO=2ms isOpen=true).onExceptionRead exception: {}
java.util.zip.ZipException: incorrect header check
---trimmed---- Caused by:java.util.zip.DataFormatException: incorrect header check
---trimmed--- 2021-08-02 06:35:21,215 NIOThread@0 INFO HTTP.CLIENT - HTTPClient$Context.logContextDetails() : Request details : host=null path=/folder/testFile method=GET. Channel details : Bytes read=0 2021-08-02 06:35:21,216 NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() : AbstractResponseListener.onError(HTTPResponse@3966e277, incorrect header check) 2021-08-02 06:35:21,216 NIOThread@0 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.util.zip.ZipException: incorrect header check occurred while writing to channel null 2021-08-02 06:35:21,217 NIOThread@0 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace: java.util.zip.ZipException: incorrect header checkLes lignes
java.util.zip.ZipException: incorrect header check
etCaused by: java.util.zip.DataFormatException: incorrect header check
dans le message d'erreur ci-dessus indiquent que la charge utile de la réponse n'est pas envoyée au format déflate et ne correspond pas à l'encodage spécifié dans l'en-têteContent-Encoding
de déflate. Par conséquent, Apigee Edge génère l'exception et renvoie un code d'état502
avec le code d'erreurmessaging.adaptors.http.flow.DecompressionFailureAtResponse
aux applications clientes.
-
Résolution
- Si la charge utile de réponse compressée n'est pas nécessaire dans le flux de proxy d'API dans Apigee Edge et dans le serveur backend, ne transmettez pas l'en-tête
Content-Encoding
. Si vous devez compresser la charge utile de la réponse, passez à l'étape 2. - S'il est nécessaire de compresser la charge utile de réponse, assurez-vous que le serveur backend envoie toujours les éléments suivants :
- N'importe quel
encodage compatible en tant que valeur de l'en-tête
Content-Encoding
dans la réponse - La charge utile de réponse au format accepté par Apigee Edge correspond au format d'encodage spécifié dans l'en-tête
Content-Encoding
- N'importe quel
encodage compatible en tant que valeur de l'en-tête
- Dans l'exemple décrit ci-dessus, la charge utile de la réponse est au format ZIP, mais l'en-tête de réponse spécifie
Content-Encoding: gzip
. Pour résoudre le problème, envoyez l'en-tête de réponse en tant queContent-Encoding: gzip
et la charge utile de la réponse au formatgzip
:curl -v https://HOSTALIAS/v1/test
> < HTTP/1.1 200 OK < Accept-Ranges: bytes <
Content-Encoding: gzip
< Date: Mon, 02 Aug 2021 08:17:35 GMT < Transfer-Encoding: chunked < < response_payload.gz Response Body(in GZIP format)>
Spécification
Apigee Edge renvoie le code d'état 502 Bad Gateway
avec le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtResponse
, conformément aux spécifications RFC suivantes:
Spécification |
---|
RFC 7231, section 6.5.1 |
RFC 7231, section 3.1.2.2 |
Si vous avez encore besoin de l'aide de l'assistance Apigee, consultez Vous devez recueillir des informations de diagnostic.
Vous devez collecter des informations de diagnostic
Rassemblez les informations de diagnostic suivantes, puis contactez l'assistance Apigee Edge:
Si vous êtes un utilisateur de cloud public, fournissez les informations suivantes:
- Le nom de l'organisation.
- Nom de l'environnement
- Nom du proxy d'API
- Complétez la commande
curl
permettant de reproduire l'erreur502
. - Fichier de suivi des réponses de l'API
Si vous êtes un utilisateur du Private Cloud, fournissez les informations suivantes:
- Message d'erreur complet observé pour les réponses en échec
- Nom de l'environnement
- Groupe de proxys d'API
- Fichier de suivi des réponses de l'API
Journaux d'accès NGINX
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Où:ORG, ENV et PORT# sont remplacés par des valeurs réelles.
- Journaux système du processeur de messages
/opt/apigee/var/log/edge-message-processor/logs/system.log