502 Bad Gateway – DecompressionFailureAtResponse

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.

Problème constaté

L'application cliente reçoit un code d'état HTTP 502 Bad Gateway avec le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtResponse en réponse aux appels d'API.

Message d'erreur

L'application cliente reçoit le code de réponse suivant :

HTTP/1.1 502 Bad Gateway

De plus, un message d'erreur semblable à celui 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 (du serveur backend/cible) Content-Encoding est valide et compatible avec Apigee Edge.

MAIS

• Le format de la charge utile envoyée par le serveur backend/cible dans la réponse HTTP ne correspond pas au format d'encodage spécifié dans l'en-tête Content-Encoding .

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 le même que celui de l'encodage spécifié dans l'en-tête Content-Encoding.

Voici quelques exemples de valeurs Content-Encoding acceptées et de la façon dont Apigee Edge s'attend à ce que la représentation de la charge utile soit dans ces cas :

Voici les causes possibles de cette erreur :

Étapes de diagnostic courantes

Utilisez l'un des outils/techniques suivants pour diagnostiquer cette erreur :

Cause : Le format de la charge utile de la réponse ne correspond pas à l'encodage du contenu

Par défaut, Apigee Edge décompresse toujours la charge utile si l'en-tête de réponse Content-Encoding contient un encodage valide et compatible. Par conséquent, le format de la charge utile de la réponse doit correspondre à l'encodage spécifié dans l'en-tête de réponse Content-Encoding. Si les informations ne correspondent pas, ce message d'erreur s'affiche.

Diagnostic

1. Déterminez le code d'erreur et la source 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 Étapes de diagnostic courantes.
2. Si le code d'erreur est messaging.adaptors.http.flow.DecompressionFailureAtResponse et que la source de l'erreur a la valeur target, cela indique que le format de la charge utile de la réponse envoyée par le serveur backend/cible ne correspond pas à l' encodage compatible spécifié dans l'en-tête de réponse Content-Encoding.

3. Vous pouvez déterminer l'incohérence dans la réponse HTTP à l'aide de l'une des méthodes suivantes :

   Message d'erreur

   Pour valider à l'aide du message d'erreur :

   1. Si vous avez accès au message d'erreur complet reçu d'Apigee Edge, consultez faultstring.

      Exemple de message d'erreur :

      "faultstring":"Decompression failure at response"

   2. 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ête Content-Encoding.

   Trace

   Pour valider à l'aide de Trace :

   1. Déterminez le Content-Type et error.cause à l'aide de Trace, comme expliqué dans Étapes de diagnostic courantes.

   2. 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. Toutefois, 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'erreur messaging.adaptors.http.flow.DecompressionFailureAtResponse.

   Demande réelle

   Pour valider les résultats à l'aide de la requête réelle :

   Si vous avez accès à la requête réelle envoyée à l'application serveur cible/backend, procédez comme suit :

   1. Si vous êtes un utilisateur de cloud public/privé, envoyez une requête directement au serveur backend depuis le serveur backend lui-même ou depuis toute autre machine à partir de laquelle vous êtes autorisé à envoyer la requête au serveur backend.
   2. Si vous êtes un utilisateur du cloud privé, vous pouvez également envoyer la requête au serveur backend depuis l'un des processeurs de messages.
   3. Examinez la réponse envoyée par le serveur backend et déterminez la valeur transmise dans l'en-tête de réponse Content-Encoding..
   4. Déterminez le format de la charge utile envoyée dans la requête.
   5. Si la valeur de l'en-tête Content-Encoding figure dans la liste des encodages acceptés, mais que le format de la charge utile de la réponse ne correspond pas à l'encodage spécifié dans l'en-tête Content-Encoding, il s'agit de 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ête Content-Encoding, qui est un encodage compatible dans Apigee Edge. Toutefois, le response_payload.zip est envoyé sous forme de fichier ZIP. Par conséquent, cette réponse échoue avec une erreur 502 Bad Gateway et le code d'erreur 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 Private Cloud, vous pouvez utiliser les journaux du processeur de messages pour déterminer les informations clés sur les erreurs HTTP 502.

   1. Consultez le journal du processeur de messages :

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

   2. Recherchez s'il existe des erreurs 502 pendant une durée spécifique (si le problème s'est produit dans le passé) ou si des réponses échouent toujours avec 502. Vous pouvez utiliser la chaîne de recherche suivante :

      grep -ri "ZipException"
      

   3. Vous trouverez des lignes de system.log semblables à celles-ci :

      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() : Exception
      java.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 format
      

      La ligne java.util.zip.ZipException: Not in GZIP format du message d'erreur ci-dessus indique que la charge utile de la réponse n'est pas envoyée au format GZIP, alors que Content-Encoding est spécifié comme gzip. Par conséquent, Apigee Edge génère l'exception et renvoie un code d'état 502 avec le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtResponse aux applications clientes.

      Scénario 2

      Scénario 2 : Lorsque la réponse de l'API contient 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 check
      
      

      Les lignes java.util.zip.ZipException: incorrect header check et Caused by: java.util.zip.DataFormatException: incorrect header check du message d'erreur ci-dessus indiquent que la charge utile de la réponse n'est pas envoyée au format deflate et ne correspond pas à l'encodage spécifié dans l'en-tête Content-Encoding de deflate. Par conséquent, Apigee Edge génère l'exception et renvoie un code d'état 502 avec le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtResponse aux applications clientes.

Solution

1. 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.
2. Si vous devez compresser la charge utile de la réponse, assurez-vous que le serveur de backend envoie toujours les éléments suivants :
   • L'un des encodages acceptés comme valeur de l'en-tête Content-Encoding dans la réponse
   • La charge utile de la réponse au format compatible avec Apigee Edge correspond au format d'encodage spécifié dans l'en-tête Content-Encoding.
3. Dans l'exemple 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, vous pouvez envoyer l'en-tête de réponse au format Content-Encoding: gzip et la charge utile de la réponse au format gzip :

   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 répond avec le code d'état 502 Bad Gateway et le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtResponse, conformément aux spécifications RFC suivantes :

Si vous avez encore besoin d'aide de l'assistance Apigee, consultez la page Vous devez collecter 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 du cloud public, fournissez les informations suivantes :

• Nom de l'organisation
• Nom de l'environnement
• Nom du proxy d'API
• Commande curl complète utilisée pour reproduire l'erreur 502
• Fichier de trace pour les réponses de l'API

Si vous êtes un utilisateur du cloud privé, fournissez les informations suivantes :

• Message d'erreur complet observé pour les réponses ayant échoué
• Nom de l'environnement
• Bundle de proxy d'API
• Fichier de trace pour les 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