400 (Requête incorrecte) – DecompressionFailureAtRequest

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 400 Bad Request avec le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtRequest en réponse aux appels d'API.

Message d'erreur

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

HTTP/1.1 400 Bad Request

De plus, un message d'erreur semblable à celui ci-dessous peut s'afficher : 

{
   "fault":{
      "faultstring":"Decompression failure at request",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"
      }
   }
}

Causes possibles

Cette erreur ne se produit que dans les cas suivants :

  • L'encodage spécifié dans l'en-tête de requête HTTP Content-Encoding est valide et compatible avec Apigee Edge.

    • MAIS

  • Le format de la charge utile envoyée par le client dans le cadre de la requête 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 la façon dont Apigee Edge s'attend à ce que le format de charge utile soit dans ces cas :

Scénario Content-Encoding Format de charge utile attendu
Encodage unique gzip

Format Unix gzip.

Consultez RFC1952 GZIP Format.

Encodage unique deflate

Ce format utilise la structure zlib avec l'algorithme de compression deflate.

Consultez les RFC1950 et RFC1951..
Encodage multiple

Encodage multiple

Par exemple, dans les cas où l'encodage est effectué deux fois, il peut s'agir de :

  • gzip, deflate
  • gzip, gzip
  • deflate, gzip
  • deflate, deflate
 Encodage multiple appliqué à la charge utile dans l'ordre indiqué dans l'en-tête.

Voici les causes possibles de cette erreur :

Cause Description Instructions de dépannage applicables
Le format de la charge utile de la requête ne correspond pas à l'encodage spécifié dans l'en-tête Content-Encoding. Le format de la charge utile de la requête envoyée par le client n'est pas encodé ou ne correspond pas à l'encodage spécifié dans l'en-tête Content-Encoding. Utilisateurs du cloud public et privé Edge

Étapes de diagnostic courantes

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

Surveillance des API

Pour diagnostiquer l'erreur à l'aide d'API Monitoring :

  1. Connectez-vous à l'UI Apigee Edge en tant qu'utilisateur disposant d'un rôle approprié.

  2. Basculez vers l'organisation dans laquelle vous souhaitez examiner le problème.

  3. Accédez à la page Analyser > API Monitoring > Examiner.
  4. Sélectionnez la période spécifique au cours de laquelle vous avez observé les erreurs.
  5. Assurez-vous que le filtre Proxy est défini sur Tous.
  6. Représentez graphiquement Code d'erreur par rapport à Heure.

  7. Sélectionnez une cellule contenant le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtRequest, comme indiqué ci-dessous :

    ( Agrandir l'image)

  8. Les informations sur le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtRequest s'affichent comme indiqué ci-dessous :

    ( Agrandir l'image)

  9. Cliquez sur Afficher les journaux, puis développez la ligne qui échoue avec l'erreur 400.

    ( agrandir l'image)

  10. Dans la fenêtre Journaux, notez les informations suivantes :
    • Code d'état : 400
    • Source de la défaillance : proxy
    • Code d'erreur : messaging.adaptors.http.flow.DecompressionFailureAtRequest.
  11. Si la source de l'erreur a la valeur proxy, cela indique que le format de la charge utile de la requête ne correspond pas à l' encodage compatible spécifié dans l'en-tête Content-Encoding.

Outil Trace

Pour diagnostiquer l'erreur à l'aide de l'outil Trace :

  1. Activez la session de trace, puis :
    1. Attendez que l'erreur 400 Bad Request se produise.
    2. Si vous pouvez reproduire le problème, effectuez l'appel d'API et reproduisez 400 Bad Request.

  2. Assurez-vous que l'option Afficher toutes les FlowInfos est activée :

  3. Sélectionnez l'une des requêtes ayant échoué et examinez la trace.
  4. Parcourez les différentes phases de la trace et identifiez l'emplacement de l'échec.

  5. L'erreur se trouve généralement dans un flux juste après la phase Requête reçue du client, comme indiqué ci-dessous :

    ( agrandir l'image)

  6. Notez les valeurs des propriétés de la trace :

    • Erreur : Decompression failure at request
    • error.class : com.apigee.rest.framework.BadRequestException
    • error.cause: : Not in GZIP format

    Le champ error.cause indique que la charge utile de la requête n'est PAS au format GZIP. Cela signifie qu'Apigee Edge s'attendait à ce que la charge utile de la requête soit au format GZIP, comme indiqué dans l'en-tête Content-Encoding.

  7. Déterminez la valeur de l'en-tête de requête Content-Encoding. Pour ce faire, accédez à la phase Demande reçue du client, comme indiqué ci-dessous :

    ( Agrandir l'image)

    Notez que la valeur de l'en-tête de requête Content-Encoding est bien gzip.

    L'exemple de trace ci-dessus montre que l'encodage spécifié dans l'en-tête de requête Content-Encoding est gzip. Toutefois, la charge utile de la requête n'est pas au format GZIP. Par conséquent, Apigee ne peut pas décompresser la charge utile à l'aide de gzip et renvoie l'erreur Decompression failure at request.

  8. Notez le code d'état et le message d'erreur renvoyés par Apigee Edge en accédant à

    à la phase Réponse envoyée au client dans la trace, comme indiqué ci-dessous :

    ( agrandir l'image)

    Notez les détails suivants dans la trace :

    • Code d'état : 400 Bad Request.
    • Contenu de l'erreur : {"fault":{"faultstring":"Decompression failure at request","detail":{"errorcode":"messaging.adaptors.http.flow.DecompressionFailureAtRequest"}}}

  9. Accédez à la phase AX (données Analytics enregistrées) dans la trace et cliquez dessus.

  10. Faites défiler la page vers le bas jusqu'aux sections Détails de la phase et En-têtes d'erreur, puis déterminez les valeurs de X-Apigee-fault-code et X-Apigee-fault-source, comme indiqué ci-dessous :

    ( Agrandir l'image)

  11. Les valeurs X-Apigee-fault-code et X-Apigee-fault-source seront respectivement messaging.adaptors.http.flow.DecompressionFailureAtRequest et policy, ce qui indique que le format de la charge utile de la requête ne correspond pas à l'encodage spécifié dans l'en-tête Content-Encoding.
    En-têtes de réponse Valeur
    X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
    X-Apigee-fault-source policy

NGINX

Pour diagnostiquer l'erreur à l'aide des journaux d'accès NGINX :

  1. Si vous êtes un utilisateur Private Cloud, vous pouvez utiliser les journaux d'accès NGINX pour déterminer les informations clés sur les erreurs HTTP 400.

  2. 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.

  3. Recherchez les éventuelles erreurs 400 sur une période spécifique (si le problème s'est produit dans le passé) ou les requêtes qui échouent encore avec 400.

  4. Si vous trouvez des erreurs 400 avec le X-Apigee-fault-code correspondant à la valeur de messaging.adaptors.http.flow.DecompressionFailureAtRequest, déterminez la valeur de X-Apigee-fault-source.

    Exemple d'erreur 400 dans le journal d'accès NGINX :

    L'exemple d'entrée ci-dessus du journal d'accès NGINX présente les valeurs suivantes pour X-Apigee-fault-code et X-Apigee-fault-source :

    En-têtes de réponse Valeur
    X-Apigee-fault-code messaging.adaptors.http.flow.DecompressionFailureAtRequest
    X-Apigee-fault-source policy

Cause : Le format de la charge utile de la requête ne correspond pas à l'encodage spécifié dans l'en-tête Content-Encoding.

Par défaut, Apigee Edge décompresse toujours la charge utile si l'en-tête de requête Content-Encoding contient un encodage valide et compatible. Par conséquent, le format de la charge utile de la requête doit correspondre à l'encodage spécifié dans l'en-tête de la requête 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.DecompressionFailureAtRequest et que la source de l'erreur a la valeur policy ou proxy, cela indique que la requête envoyée par l'application cliente comporte une charge utile qui ne correspond pas à l' encodage compatible spécifié dans l'en-tête de requête Content-Encoding.

  3. Vous pouvez déterminer l'incohérence dans la requête 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 request"
    2. Dans le message d'erreur ci-dessus, "Decompression failure at request" s'affiche, ce qui implique que la requête 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 la valeur de l'en-tête de requête Content-Encoding et de la propriété 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 requête Content-Encoding est gzip. Toutefois, la charge utile de la requête n'est pas au format GZIP (comme indiqué par error.cause). Par conséquent, Apigee Edge répond avec 400 Bad Request et le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtRequest.

    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 effectuée par l'application cliente, procédez comme suit :

    1. Déterminez la valeur transmise à l'en-tête de requête Content-Encoding.
    2. Déterminez le format de la charge utile envoyée dans la requête.

    3. 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 requête ne correspond pas à l'encodage spécifié dans l'en-tête Content-Encoding, il s'agit de la cause du problème.

      Exemple de demande :

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

      L'exemple de requête ci-dessus envoie la valeur gzip à l'en-tête Content-Encoding, qui est un encodage compatible dans Apigee Edge. Toutefois, la charge utile de la requête request_payload.zip est au format ZIP. Par conséquent, cette requête échoue avec un code d'état 400 Bad Request et le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtRequest.

    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 400.

    1. Déterminez l'ID du message de la requête ayant échoué à l'aide de l'outil API Monitoring, de l'outil Trace ou des journaux d'accès NGINX, comme expliqué dans Étapes de diagnostic courantes.

    2. Recherchez l'ID du message dans le journal du processeur de messages :

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

    3. L'une des exceptions suivantes s'affiche :

      Scénario 1

      Scénario 1 : Lorsque la requête API comporte l'en-tête Content-Encoding: gzip

      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

      La ligne java.util.zip.ZipException: Not in GZIP format du message d'erreur ci-dessus indique que la charge utile de la requête 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 400 avec le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtRequest aux applications clientes.

      Scénario 2

      Scénario 2 : Lorsque la requête d'API comporte l'en-tête Content-Encoding: deflate

      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)

      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 requête 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 400 avec le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtRequest aux applications clientes.

Solution

  1. Si la charge utile de la requête 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 requête, passez à l'étape 2.
  2. Assurez-vous que l'application cliente envoie toujours les éléments suivants :
    • Toute l'encodage pris en charge comme valeur de l'en-tête Content-Encoding dans la requête
    • La charge utile de la requête 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 requête est au format ZIP, mais l'en-tête de requête spécifie Content-Encoding: gzip. Pour résoudre le problème, vous pouvez envoyer l'en-tête de requête au format Content-Encoding: gzip et la charge utile de la requête au format gzip : 
    curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.gz

Spécification

Apigee Edge répond avec le code d'état 400 Bad Request et le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtRequest, 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 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 400
  • Fichier de trace pour les requêtes API

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

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