502 Bad Gateway – TooBigBody

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 502 Bad Gateway avec le code d'erreur protocol.http.TooBigBody en réponse aux appels d'API.

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 cette erreur :

Étapes de diagnostic courantes

Utilisez l'un des outils/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 pour l'erreur observée à l'aide d'API Monitoring, de l'outil Trace ou des journaux d'accès NGINX, comme expliqué dans Étapes de diagnostic courantes avec le scénario 1.
2. Si la source de l'erreur a la valeur target, cela indique que la taille de la charge utile de la 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, il s'agit de la cause de l'erreur.
   • Si la taille de la charge utile est proche de la limite autorisée de 10 Mo, il est possible que la charge utile de la réponse soit transmise au format compressé. Accédez à Cause : La taille de la charge utile de la réponse dépasse la limite autorisée après décompression.
4. Validez que la taille de la charge utile de la réponse est effectivement supérieure à la limite autorisée de 10 Mo en vérifiant la réponse réelle à l'aide des étapes suivantes :
   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/privé, envoyez une requête directement au serveur backend depuis le serveur backend lui-même ou depuis toute autre machine à partir de laquelle vous êtes autorisé à envoyer la requête au serveur backend.
      2. Si vous êtes un utilisateur du cloud privé, vous pouvez également envoyer la requête au serveur backend depuis l'un des processeurs de messages.
      3. Vérifiez la taille de la charge utile transmise dans la réponse en consultant l'en-tête Content-Length.
      4. Si vous constatez que la taille de la charge utile est supérieure à la limite autorisée dans Apigee Edge, il s'agit de 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 voir que Content-Length: 11534336 (which is ~11 MB) est à l'origine de cette erreur, car il dépasse la limite autorisée dans Apigee Edge.

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. Pendant le processus de décompression, si Apigee constate que la taille de la charge utile est supérieure à la limite autorisée dans Apigee Edge, il arrête la 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 de la surveillance de l'API, de l'outil Trace ou des journaux d'accès NGINX, comme expliqué dans Étapes de diagnostic courantes avec le scénario 2.
2. Si la source de l'erreur a la valeur target, cela signifie que la taille de la charge utile de la réponse envoyée par l'application cible/de 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, il s'agit de la cause de l'erreur.
   • Si la taille de la charge utile est proche de la limite autorisée de 10 Mo, il est possible que la charge utile de la réponse soit transmise au 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 au 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 pour la requête ayant échoué, reportez-vous aux étapes décrites dans Trace et
      .
      1. Déterminez la valeur de target.received.content.length.
      2. Vérifiez si la requête du client contenait l'en-tête Content-Encoding: gzip .
   2. Si la valeur de target.received.content.length est proche de la limite autorisée de 10 Mo et que l'en-tête de réponse Content-Encoding: gzip est présent, il s'agit de la cause de cette erreur.

   Demande réelle

   Utiliser la 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

   Utiliser les journaux du processeur de messages :

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

   2. Vérifier les journaux du processeur de messages

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

   3. Recherchez les éventuelles erreurs 502 sur une période spécifique (si le problème s'est produit dans le passé) ou les requêtes qui échouent encore avec 502. Vous pouvez utiliser les chaînes de recherche suivantes :

      grep -ri "chunkCount"
      

      grep -ri "BadGateway: Body buffer overflow"
      

   4. Vous trouverez 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. Lors 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 signifie que la taille de la charge utile de la réponse est supérieure à 10 Mo. 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.

Solution

Limites

Apigee s'attend à ce que l'application cliente et le serveur backend n'envoient pas de charges utiles dont la taille dépasse la limite autorisée, comme indiqué pour Request/response size dans Limites d'Apigee Edge.

1. Si vous êtes un utilisateur du cloud public, la limite maximale de la taille de la charge utile des requêtes et des réponses est celle documentée pour Request/response size dans les limites d'Apigee Edge.
2. Si vous êtes un utilisateur Private Cloud , vous avez peut-être modifié la limite maximale par défaut pour la taille de la charge utile des requêtes et des réponses (même si ce n'est pas une pratique recommandée). Pour déterminer la limite de taille maximale de la charge utile de la 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 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 définie, comme indiqué ci-dessous :

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

2. Voici un exemple de résultat de la commande ci-dessus :

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

3. Dans l'exemple de résultat 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 limite de taille de la charge utile de la requête configurée dans Apigee pour Private Cloud est de 10 Mo.

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 502
• Fichier de trace pour les requêtes API
• Sortie complète de la réponse du serveur cible/backend, ainsi que la taille de la charge utile

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'organisation
• Nom de l'environnement
• Bundle de proxy d'API
• Fichier de trace pour les requêtes API défaillantes
• Commande curl complète utilisée pour reproduire l'erreur 502
• Sortie complète 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