400 (Requête incorrecte) – DecompressionFailureAtRequest

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

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 :

  • Le codage spécifié dans l'en-tête de requête HTTP Content-Encoding est valide et <ph type="x-smartling-placeholder"></ph> 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 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 le format de la charge utile soit dans ces cas:

Scénario Content-Encoding Format de charge utile attendu
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 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é 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:

Surveillance des API

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

Pour diagnostiquer l'erreur à l'aide de l'API Monitoring, procédez comme suit:

  1. <ph type="x-smartling-placeholder"></ph> Connectez-vous à l'interface utilisateur d'Apigee Edge en tant qu'utilisateur disposant d'un rôle approprié.

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

  3. Accédez à Analyser > Surveillance des API > 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 le code d'erreur par rapport à l'heure.

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

    ( Agrandir l'image)

  8. Informations sur le code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtRequest s'affiche comme suit:

    ( Agrandir l'image)

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

    ( Agrandir l'image)

  10. Dans la fenêtre Journaux, notez les détails suivants: <ph type="x-smartling-placeholder">
      </ph>
    • Code d'état:400
    • Source de l'erreur:proxy
    • Code d'erreur:messaging.adaptors.http.flow.DecompressionFailureAtRequest.
  11. Si la source de la défaillance a la valeur proxy, cela indique que le format de la charge utile de la requête ne correspondait pas au <ph type="x-smartling-placeholder"></ph> encodage pris en charge spécifié dans l'en-tête Content-Encoding.

Outil Trace

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

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

  1. Activez la session de trace. et l'une des options suivantes: <ph type="x-smartling-placeholder">
      </ph>
    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 les actions 400 Bad Request

  2. Assurez-vous que l'option Show all FlowInfos (Afficher toutes les informations FlowInfos) est activée:

  3. Sélectionnez l'une des requêtes ayant échoué et examinez la trace.
  4. Parcourir les différentes phases de la trace et localiser l'origine de la défaillance s'est produit.

  5. Vous trouverez généralement l'erreur dans un flux juste après le Demande 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

    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, passez à 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 naviguant

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

    ( Agrandir l'image)

    Notez les détails suivants issus 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'à la section Phase Details (Détails de la phase), Error Headers (En-têtes d'erreur) et Déterminer les valeurs de X-Apigee-fault-code et X-Apigee-fault-source comme indiqué ci-dessous:

    ( Agrandir l'image)

  11. Vous verrez les valeurs de X-Apigee-fault-code et X-Apigee-fault-source. en tant que messaging.adaptors.http.flow.DecompressionFailureAtRequest et policy, qui indique que le format de la charge utile de la requête ne correspond pas au 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

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

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

  1. Si vous êtes un utilisateur du Private Cloud, vous pouvez utiliser les journaux d'accès NGINX pour déterminer les informations clés concernant 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. Effectuez une recherche pour voir s'il existe des erreurs 400 pendant une durée spécifique (si le problème s'est produit dans le passé) ou si des requêtes échouent encore avec 400

  4. Si vous trouvez des erreurs 400 avec le code X-Apigee-fault-code correspondant à la valeur de messaging.adaptors.http.flow.DecompressionFailureAtRequest, puis déterminer 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-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 la requête 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 requête doit correspondre à l'encodage spécifié dans l'en-tête de requête 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.DecompressionFailureAtRequest et les Source de la défaillance a la valeur policy ou proxy, alors cette indique que la requête envoyée par l'application cliente a une charge utile qui ne correspond pas à celle compatible spécifié dans l'en-tête de requête Content-Encoding.

  3. Vous pouvez déterminer la non-concordance dans la requête 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 request"
    2. Dans le message d'erreur ci-dessus, il affiche "Decompression failure at request", ce qui implique que la requête 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 la valeur de l'en-tête de requête Content-Encoding et du paramètre Propriété error.cause avec 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 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 code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtRequest

    Demande réelle

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

    Si vous avez accès à la demande réelle faite par le client , puis effectuez les étapes suivantes:

    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 <ph type="x-smartling-placeholder"></ph> encodage pris en charge, mais le format de la charge utile de la requête correspond à 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 au Content-Encoding, qui est une <ph type="x-smartling-placeholder"></ph> compatible avec l'encodage d'Apigee Edge. Cependant, la charge utile de la requête request_payload.zip est au format ZIP. Par conséquent, cette demande échoue avec l'affichage du code d'état 400 Bad Request et le code d'erreur: messaging.adaptors.http.flow.DecompressionFailureAtRequest

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

    1. Déterminez l'ID du message de la requête ayant échoué à l'aide de l'API Monitoring, de l'outil Trace ou 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 requête 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 400 avec un 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 dans le message d'erreur ci-dessus indiquent que la charge utile de la requête 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 400 avec code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtRequest aux applications clientes.

Solution

  1. S'il n'est pas nécessaire de la charge utile de requête 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 requête, passez à l'étape 2.
  2. Assurez-vous que l'application cliente 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 demander
    • La charge utile de la requête envoyée à Apigee Edge au format compatible correspond à l'encodage. format spécifié dans l'en-tête Content-Encoding
  3. Dans l'exemple présenté ci-dessus, la charge utile de la requête est au format ZIP, mais l'en-tête de la requête spécifie Content-Encoding: gzip. Vous pouvez résoudre le problème en envoyant la demande en-tête Content-Encoding: gzip et la charge utile de la requête également dans gzip format: 
    curl -v "https://HOSTALIAS/v1/testgzip" -H "Content-Encoding: gzip" -X POST -d @request_payload.gz
    <ph type="x-smartling-placeholder">

Spécification

Apigee Edge répond avec le code d'état 400 Bad Request avec un code d'erreur messaging.adaptors.http.flow.DecompressionFailureAtRequest, 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 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 en échec
  • 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 les valeurs réelles.

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