502 Bad Gateway – TooBigBody

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

Problème constaté

En réponse aux appels d'API, l'application cliente reçoit un code d'état HTTP 502 Bad Gateway avec le code d'erreur protocol.http.TooBigBody .

Message d'erreur

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

HTTP/1.1 502 Bad Gateway

De plus, le message d'erreur suivant peut s'afficher:

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

Causes possibles

Cette erreur se produit si la taille de la charge utile envoyée par le serveur cible/backend à Apigee Edge dans le cadre de la réponse HTTP est supérieure à la limite autorisée dans Apigee Edge.

Voici les causes possibles de l'erreur:

Cause	Description	Instructions de dépannage applicables
La taille de la charge utile de la réponse est supérieure à la limite autorisée	La taille de la charge utile envoyée par le serveur cible/backend dans la réponse HTTP à Apigee est supérieure à la limite autorisée dans Apigee.	Utilisateurs Edge Public and Private Cloud
La taille de la charge utile de la réponse dépasse la limite autorisée après décompression	La taille de la charge utile envoyée au format compressé par le serveur cible/backend dans la réponse HTTP à Apigee est supérieure à la limite autorisée lorsqu'elle est décompressée par Apigee.	Utilisateurs Edge Public and Private Cloud

Étapes de diagnostic courantes

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

Cause: la taille de la charge utile de la réponse est supérieure à la limite autorisée

Diagnostic

1. Déterminez le code d'erreur, la source de l'erreur et la taille de la charge utile de la réponse 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 avec le scénario 1.
2. Si la source d'erreur a la valeur target, cela indique que la taille de la charge utile de réponse envoyée par le serveur cible/backend à Apigee est supérieure à la limite autorisée dans Apigee Edge.
3. Vérifiez la taille de la charge utile de la réponse déterminée à l'étape 1.
   • Si la taille de la charge utile dépasse la limite autorisée de 10 Mo, l'erreur est due.
   • Si la taille de la charge utile est d'environ 10 Mo, il est possible que la charge utile de la réponse soit transmise dans un format compressé. Consultez Cause: la taille de la charge utile de la réponse dépasse la limite autorisée après la décompression.
4. Vérifiez que la taille de la charge utile de la réponse est bien supérieure à la limite autorisée de 10 Mo en vérifiant la réponse réelle en procédant comme suit :
   1. Si vous n'avez pas accès à la requête réelle envoyée au serveur cible/backend, accédez à Résolution.
   2. Si vous avez accès à la requête réelle envoyée au serveur cible/backend, procédez comme suit :
      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 machine à partir de laquelle vous êtes autorisé à envoyer la requête au serveur backend.
      2. Si vous êtes un utilisateur de cloud privé, vous pouvez également envoyer la requête au serveur backend à partir de l'un des processeurs de messages.
      3. Vérifiez la taille de la charge utile transmise dans la réponse en vérifiant l'en-tête Content-Length.
      4. Si vous constatez que la taille de la charge utile dépasse la limite autorisée dans Apigee Edge, c'est la cause du problème.

   Exemple de réponse du serveur backend:

   curl -v https://BACKENDSERVER-HOSTNAME/testfile
   

   * About to connect() to 10.14.0.10 port 9000 (#0)
   *   Trying 10.14.0.10...
   * Connected to 10.14.0.10 (10.148.0.10) port 9000 (#0)
   > GET /testfile HTTP/1.1
   > User-Agent: curl/7.29.0
   > Host: 10.14.0.10:9000
   > Accept: */*
   >
   < HTTP/1.1 200 OK
   < Accept-Ranges: bytes
   < Content-Length: 11534336
   < Content-Type: application/octet-stream
   < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
   < Date: Wed, 30 Jun 2021 09:22:41 GMT
   <
   ----snipped----
   <Response Body>
   

   Dans l'exemple ci-dessus, vous pouvez constater que Content-Length: 11534336 (which is ~11 MB) est la cause de cette erreur, car il dépasse la limite autorisée dans Apigee Edge.

Résolution

Consultez la section Résolution.

Cause: la taille de la charge utile de la réponse dépasse la limite autorisée après décompression

Si la charge utile de la réponse est envoyée au format compressé et que l'en-tête de réponse Content-Encoding est défini sur gzip, Apigee décompresse la charge utile de la réponse. Au cours du processus de décompression, si Apigee détermine que la taille de la charge utile est supérieure à la limite autorisée dans Apigee Edge, il arrête une nouvelle décompression et répond immédiatement avec 502 Bad Gateway et le code d'erreur protocol.http.TooBigBody.

Diagnostic

1. Déterminez le code d'erreur, la source de l'erreur et la taille de la charge utile de la réponse pour l'erreur observée à l'aide des journaux d'accès de l'API Monitoring, de Trace Tool ou de NGINX, comme expliqué dans la section Étapes de diagnostic courantes avec le scénario 2.
2. Si la source d'erreur a la valeur target, cela indique que la taille de la charge utile de réponse envoyée par l'application cible/backend à Apigee est supérieure à la limite autorisée dans Apigee Edge.
3. Vérifiez la taille de la charge utile de la réponse déterminée à l'étape 1.
   • Si la taille de la charge utile dépasse la limite autorisée de 10 Mo, l'erreur est due.
   • Si la taille de la charge utile est d'environ 10 Mo, il est possible que la charge utile de la réponse soit transmise dans un format compressé. Dans ce cas, vérifiez la taille non compressée de la charge utile de réponse compressée.
4. Vous pouvez vérifier si la réponse de la cible/du backend a été envoyée dans un format compressé et si la taille non compressée était supérieure à la limite autorisée à l'aide de l'une des méthodes suivantes:

   Trace

   Utiliser l'outil Trace:

   1. Si vous avez capturé une trace de la requête ayant échoué, reportez-vous à la procédure détaillée dans Trace et
      1. Déterminer la valeur de target.received.content.length
      2. Vérifiez si la requête du client contient l'en-tête Content-Encoding: gzip .
   2. Si la valeur de target.received.content.length se situe autour de la limite autorisée de 10 Mo et de l'en-tête de réponse target.received.content.length , c'est la cause de cette erreur.

   Demande réelle

   Utilisation d'une requête réelle :

   1. Si vous n'avez pas accès à la requête réelle envoyée au serveur cible/backend, accédez à Résolution.
   2. Si vous avez accès à la requête réelle envoyée au serveur cible/backend, procédez comme suit :
      1. Vérifiez la taille de la charge utile transmise dans la réponse ainsi que l'en-tête Content-Encoding envoyé dans la réponse.
      2. Si vous constatez que l'en-tête de réponse Content-Encoding est défini sur gzip et que la taille non compressée de la charge utile est supérieure à la limite autorisée dans Apigee Edge, c'est la cause de cette erreur.

         Exemple de réponse reçue du serveur backend:

         curl -v https://BACKENDSERVER-HOSTNAME/testzippedfile.gz
         

         * About to connect() to 10.1.0.10 port 9000 (#0)
         *   Trying 10.1.0.10...
         * Connected to 10.1.0.10 (10.1.0.10) port 9000 (#0)
         > GET /testzippedfile.gz HTTP/1.1
         > User-Agent: curl/7.29.0
         > Host: 10.1.0.10:9000
         > Accept: */*
         >
         < HTTP/1.1 200 OK
         < Accept-Ranges: bytes
         < Content-Encoding: gzip
         < Content-Type: application/x-gzip
         < Last-Modified: Wed, 30 Jun 2021 08:18:02 GMT
         < Testheader: test
         < Date: Wed, 07 Jul 2021 10:14:16 GMT
         < Transfer-Encoding: chunked
         <
         ----snipped----
         <Response Body>
         

         Dans le cas ci-dessus, l'en-tête Content-Encoding: gzip est envoyé et la taille du fichier testzippedfile.gz dans la réponse est inférieure à la limite. Toutefois, la taille du fichier non compressé testzippedfile était d'environ 15 Mo.

   Journaux du processeur de messages

   Utilisation des journaux du processeur de messages:

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

   2. Vérifier les journaux du processeur de messages

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

   3. Recherchez s'il existe des erreurs 502 pendant une durée spécifique (si le problème s'est produit par le passé) ou si des requêtes échouent toujours avec 502. Vous pouvez utiliser les chaînes de recherche suivantes:

      grep -ri "chunkCount"
      

      grep -ri "BadGateway: Body buffer overflow"
      

   4. Vous verrez des lignes de system.log semblables à celles ci-dessous (TotalRead et chunkCount peuvent varier dans votre cas) :

      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.SERVICE -
      TrackingInputChannel.checkMessageBodyTooLarge() : Message is too large.
      TotalRead 10489856 chunkCount 2571
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR HTTP.CLIENT -
      HTTPClient$Context.onInputException() :
      ClientInputChannel(ClientChannel[Connected:
      Remote:10.148.0.10:9000 Local:10.148.0.9:42240]@9155
      useCount=1 bytesRead=0 bytesWritten=182 age=23ms  lastIO=0ms
      isOpen=true).onExceptionRead exception: {}
      com.apigee.errors.http.server.BadGateway: Body buffer overflow
      
      2021-07-07 09:40:47,012  NIOThread@7 ERROR
      ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
      AbstractResponseListener.onError(HTTPResponse@77cbd7c4,
      Body buffer overflow)
      

   5. Au cours du processus de décompression, dès que le processeur de messages détermine que le nombre total d'octets lus est supérieur à 10 Mo, il s'arrête et affiche la ligne suivante:

      Message is too large. TotalRead 10489856 chunkCount 2571

      Cela implique que la taille de la charge utile de la réponse (Response Payload Size) est supérieure à 10 Mo et Apigee génère l'erreur lorsque la taille commence à dépasser la limite de 10 Mo avec le code d'erreur protocol.http.TooBigBody.

Résolution

Limites

Apigee s'attend à ce que l'application cliente et le serveur backend n'envoient pas de tailles de charge utile supérieures à la limite autorisée, comme indiqué pour Request/response size dans Limites Apigee Edge.

1. Si vous êtes un utilisateur de cloud public, la limite maximale de taille de la charge utile de requête et de réponse est indiquée pour Request/response size dans Limites d'Apigee Edge.
2. Si vous êtes un utilisateur du cloud privé , vous avez peut-être modifié la limite maximale par défaut de la taille des charges utiles de requête et de réponse (même si ce n'est pas une pratique recommandée). Pour déterminer la taille maximale de la charge utile de requête, suivez les instructions de la section Vérifier la limite actuelle.

Comment vérifier la limite actuelle ?

Cette section explique comment vérifier que la propriété HTTPResponse.body.buffer.limit a été mise à jour avec une nouvelle valeur sur les processeurs de messages.

1. Sur la machine de processeur de messages, recherchez la propriété HTTPResponse.body.buffer.limit dans le répertoire /opt/apigee/edge-message- processor/conf et vérifiez la valeur qui a été définie, comme indiqué ci-dessous:

   grep -ri "HTTPResponse.body.buffer.limit" /opt/apigee/edge-message-processor/conf
   

2. L'exemple de résultat de la commande ci-dessus est le suivant:

   /opt/apigee/edge-message-processor/conf/http.properties:HTTPResponse.body.buffer.limit=10m
   

3. Dans l'exemple de sortie ci-dessus, notez que la propriété HTTPResponse.body.buffer.limit a été définie avec la valeur 10m dans http.properties.

   Cela indique que la taille maximale de la charge utile de requête configurée dans Apigee pour le cloud privé est de 10 Mo.

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
• Commande curl complète utilisée pour reproduire l'erreur 502
• Fichier de suivi des requêtes API
• Résultat complet de la réponse du serveur cible/backend, ainsi que la taille de la charge utile

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

• Message d'erreur complet observé pour les requêtes ayant échoué
• Le nom de l'organisation.
• Nom de l'environnement
• Groupe de proxys d'API
• Fichier de suivi des requêtes API ayant échoué
• Commande curl complète utilisée pour reproduire l'erreur 502
• Résultat complet de la réponse du serveur cible/backend, ainsi que la taille de la charge utile

• 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