400 (Requête incorrecte) – DecompressionFailureAtRequest

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

Problème constaté

En réponse à des appels d'API, l'application cliente obtient un code d'état HTTP 400 Bad Request avec le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtRequest .

Message d'erreur

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

HTTP/1.1 400 Bad Request

En outre, un message d'erreur semblable à celui présenté 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é 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 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 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 la section Format GZIP RFC1952.

Encodage unique dégonfler

Ce format utilise une structure zlib avec un algorithme de compression "Deflate".

Voir les documents RFC 1950 et RFC 1951.
Encodage multiple

Encodage multiple

Par exemple, si l'encodage est effectué deux fois, voici les possibilités qui s'offrent à vous:

  • gzip, dégonfler
  • gzip et gzip
  • deflate, gzip
  • dégonfler, dégonfler
 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 requête ne correspond pas à l'encodage spécifié dans l'en-tête Content-Encoding Le format de la charge utile de 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 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:

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

  2. Accédez à l'organisation dans laquelle vous souhaitez examiner le problème.

  3. Accédez à la page Analyze > API Monitoring > Investigate (Analyser > Surveillance des API > Enquêter).
  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. Tracez le code d'erreur par rapport à l'heure.

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

    ( Afficher l'image plus grande)

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

    ( Afficher l'image plus grande)

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

    ( Afficher l'image plus grande)

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

Outil de traçage

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

  1. Activez la session de trace, puis effectuez l'une des opérations suivantes :
    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 Show all FlowInfos (Afficher tous 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 localisez l'origine de l'échec.

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

    ( Afficher l'image plus grande)

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

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

    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 Request Received from Client (Demande reçue du client) comme indiqué ci-dessous:

    ( Afficher l'image plus grande)

    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. Cependant, 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é par Apigee Edge en accédant

    à la phase Response sent to Client (Réponse envoyée au client) dans la trace, comme indiqué ci-dessous:

    ( Afficher l'image plus grande)

    Notez les informations suivantes à partir de 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 analytiques enregistrées) dans la trace et cliquez dessus.

  10. 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:

    ( Afficher l'image plus grande)

  11. Vous verrez les valeurs de X-Apigee-fault-code et X-Apigee-fault-source comme messaging.adaptors.http.flow.DecompressionFailureAtRequest et policy, ce qui indique que le format de la charge utile de la requête ne correspondait 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, procédez comme suit:

  1. 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 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 s'il existe des erreurs 400 pendant une durée spécifique (si le problème s'est produit par le passé) ou si des requêtes échouent toujours 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-code

    Exemple d'erreur 400 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.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 compatible valide. Par conséquent, il est normal que le format de la charge utile de la requête correspond à l'encodage spécifié dans l'en-tête de requête Content-Encoding. Si ce n'est pas le cas, ce message d'erreur s'affiche.

Diagnostic

  1. Déterminez le code d'erreur et la source de l'erreur de l'erreur observée à l'aide de l'API Monitoring, de l'outil Trace ou des journaux d'accès NGINX, comme expliqué dans la section Étapes de diagnostic courantes.
  2. Si le code d'erreur est messaging.adaptors.http.flow.DecompressionFailureAtRequest et que la source d'erreur a la valeur policy ou proxy, cela indique que la requête envoyée par l'application cliente a une charge utile qui ne correspond pas à l' encodage pris en charge spécifié dans l'en-tête de requête Content-Encoding.

  3. Vous pouvez déterminer la non-concordance dans le cadre de 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, reportez-vous au 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 la propriété 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:gzip
      • error.cause::Not in GZIP format

      La valeur de l'en-tête de requête Content-Encoding est gzip. Cependant, 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 à l'aide de la requête réelle:

    Si vous avez accès à la requête réelle envoyé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 le cadre de 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, c'est la cause du problème.

      Exemple de requête:

      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. Cependant, la charge utile de la requête request_payload.zip est au format ZIP. Par conséquent, cette requête échoue avec le code d'état 400 Bad Request et le code d'erreur suivant : 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 du cloud privé, 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 de message de la requête ayant échoué à l'aide de l'API Monitoring, de l'outil Trace ou des journaux d'accès NGINX, comme expliqué dans la section É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 dans le 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 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 déflate et ne correspond pas à l'encodage spécifié dans l'en-tête Content-Encoding de déflate. 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.

Résolution

  1. Si la charge utile de 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. S'il est nécessaire de 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 :
    • N'importe quel encodage compatible en tant que 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 décrit 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, envoyez l'en-tête de requête en tant que 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 renvoie le code d'état 400 Bad Request avec 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 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'erreur 400.
  • Fichier de suivi des requêtes API

Si vous êtes un utilisateur du Private Cloud, fournissez les informations suivantes:

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