502 Bad Gateway – DecompressionFailureAtResponse

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

L'application cliente obtient le code d'état HTTP 502 Bad Gateway avec un code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtResponse en réponse à l'API appels.

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 de l'en-tête backend/serveur cible) Content-Encoding est valide et <ph type="x-smartling-placeholder"></ph> compatible avec Apigee Edge,

MAIS

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

Ceci est dû au fait qu'Apigee Edge ne parvient pas à décoder la charge utile à l'aide de l'encodage spécifié puisque le format de la charge utile n'est pas dans le même format que l'encodage spécifié dans En-tête Content-Encoding.

<ph type="x-smartling-placeholder">

Voici quelques exemples de valeurs Content-Encoding acceptées et comment 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 gzip. Voir <ph type="x-smartling-placeholder"></ph> Format RFC1952 GZIP
Encodage unique	faire baisser	Ce format utilise la structure zlib avec un algorithme de compression de décompression. Voir <ph type="x-smartling-placeholder"></ph> RFC1950 et <ph type="x-smartling-placeholder"></ph> RFC1951.
Encodages multiples	Encodages multiples Par exemple, lorsque l'encodage est effectué deux fois, voici ce qui peut se produire: gzip, deflate gzip, gzip deflate, gzip décompresser, dégonfler	Plusieurs encodages sont appliqués à la charge utile dans l'ordre donné, tel qu'il apparaît dans l'en-tête.

Les causes possibles de cette erreur sont les suivantes:

Cause	Description	Instructions de dépannage applicables
<ph type="x-smartling-placeholder"></ph> Le format de la charge utile de réponse ne correspond pas à Content-Encoding	Le format de la charge utile de réponse envoyée par le serveur backend/cible est soit n'est pas codée ou n'est pas correspond à l'encodage spécifié dans l'en-tête Content-Encoding.	Utilisateurs Edge de cloud public et privé

Étapes de diagnostic courantes

Utilisez l'une des techniques ou l'un des outils suivants pour diagnostiquer ce problème:

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

Par défaut, Apigee Edge décompresse toujours la charge utile si l'en-tête de réponse Content-Encoding contient une valeur valide et un <ph type="x-smartling-placeholder"></ph> encodage compatible. Par conséquent, il est attendu que 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. En cas de non-concordance, vous obtenez cette erreur.

Diagnostic

1. Déterminez le code d'erreur et la source d'erreur pour l'erreur observée à l'aide de l'API. Monitoring, l'outil Trace ou les 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 les Source de la défaillance a la valeur target, alors cette indique que le format de la charge utile de réponse envoyée par le serveur backend/cible ne correspond pas au <ph type="x-smartling-placeholder"></ph> compatible avec l'encodage spécifié dans l'en-tête de réponse Content-Encoding.

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

   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, reportez-vous à faultstring.

      Exemple de message d'erreur:

      "faultstring":"Decompression failure at response"
      

   2. Dans le message d'erreur ci-dessus, il affiche "Decompression failure at response", ce qui implique que la réponse n'ont pas pu être décompressées à l'aide de l'encodage spécifié dans le Content-Encoding.

   Trace

   Pour valider à l'aide de Trace:

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

   2. Les valeurs de l'exemple de trace sont les suivantes:

      • Content-Encoding (Encodage du contenu) : gzip
      • error.cause::Not in GZIP format

      La valeur dans 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 code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtResponse

   Demande réelle

   Pour effectuer la validation à l'aide de la requête réelle:

   Si vous avez accès à la requête réelle adressée au serveur cible/backend , puis effectuez les étapes suivantes:

   1. 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 à partir de laquelle vous êtes autorisé à adresser une requête au serveur backend.
   2. Si vous êtes un utilisateur du Private Cloud, vous pouvez également effectuer la requête au serveur backend depuis l'un des processeurs de messages.
   3. Examiner la réponse envoyée par le serveur backend et déterminer la valeur transmis 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 <ph type="x-smartling-placeholder"></ph> un encodage pris en charge, mais le format de la charge utile de la réponse ne correspond pas à l'encodage spécifié dans l'en-tête Content-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 au Content-Encoding, qui est une <ph type="x-smartling-placeholder"></ph> compatible avec l'encodage d'Apigee Edge. Toutefois, response_payload.zip est envoyé sous forme de fichier ZIP. Par conséquent, cette échoue et affiche l'erreur 502 Bad Gateway avec le code d'erreur suivant: messaging.adaptors.http.flow.DecompressionFailureAtResponse

   Journaux de processeur de messages

   <ph type="x-smartling-placeholder">

   Pour valider l'utilisation 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.

   1. Consultez le journal du processeur de messages:

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

   2. Effectuez une recherche pour voir s'il y a des erreurs 502 au cours d'une durée (si le problème s'est produit dans le passé) ou s'il existe 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 à 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() : 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 dans le message d'erreur ci-dessus indique que la réponse la charge utile n'est pas envoyée au format GZIP bien que Content-Encoding est spécifiée en tant que gzip. Par conséquent, Apigee Edge génère l'exception renvoie un code d'état 502 avec un code d'erreur messaging.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 check
      
      

      Les lignes java.util.zip.ZipException: incorrect header check et Caused 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 de gonfler et ne correspond pas au codage spécifié dans En-tête Content-Encoding de la décompression. Par conséquent, Apigee Edge génère l'exception et renvoie un code d'état 502 avec code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtResponse aux applications clientes.

Solution

1. S'il n'est pas nécessaire de la charge utile de réponse compressée dans le flux de proxy d'API dans Apigee Edge et au serveur backend, ne transmettez pas l'en-tête Content-Encoding. Si vous avez besoin de compresser la charge utile de la réponse, passez à l'étape 2.
2. S'il est nécessaire de compresser la charge utile de la réponse, assurez-vous que le serveur backend envoie toujours les éléments suivants: <ph type="x-smartling-placeholder">
   </ph>
   • N'importe quelle <ph type="x-smartling-placeholder"></ph> compatible avec le codage comme valeur de l'en-tête Content-Encoding dans réponse
   • La charge utile de la réponse au format pris en charge vers Apigee Edge correspond à l'encodage format spécifié dans l'en-tête Content-Encoding
3. Dans l'exemple discuté 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. Vous pouvez résoudre le problème en envoyant la réponse l'en-tête en tant que Content-Encoding: gzip et la charge utile de la réponse dans gzip format:

   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)>
   

   <ph type="x-smartling-placeholder">

Spécification

Apigee Edge répond avec le code d'état 502 Bad Gateway avec un code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtResponse, conformément au document RFC suivant spécifications:

Spécification
<ph type="x-smartling-placeholder"></ph> RFC 7231, section 6.5.1
<ph type="x-smartling-placeholder"></ph> RFC 7231, section 3.1.2.2

Si vous avez encore besoin de l'aide de l'assistance Apigee, consultez doit 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:

• Nom de l'organisation
• Nom de l'environnement
• Nom du proxy d'API
• Exécutez la commande curl utilisée pour reproduire l'erreur 502.
• 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 les valeurs réelles.

• Journaux système du processeur de messages /opt/apigee/var/log/edge-message-processor/logs/system.log