502 Bad Gateway – TooBigBody

<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 502 Bad Gateway avec un 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

Le message d'erreur suivant peut également 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 réponse HTTP est supérieure à la limite autorisée dans Apigee Edge.

Voici les causes possibles de cette 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 dépasse la limite autorisée dans Apigee.	Utilisateurs Edge de cloud public et privé
La taille de la charge utile de la réponse dépasse la limite autorisée après décompression	Taille de la charge utile envoyée dans un format compressé par le serveur cible/backend dans le cadre d'un la réponse à Apigee dépasse la limite autorisée lors de la décompression par Apigee.	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:

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 de la surveillance des API, de l'outil Trace ou des journaux d'accès NGINX comme expliqué dans Étapes de diagnostic courantes pour le scénario 1.
2. Si la source de l'erreur a la valeur target, cela indique que la réponse la taille de la charge utile envoyée par le serveur cible/backend à Apigee est supérieure à 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 > une limite de 10 Mo autorisée, c'est la cause de l'erreur.
   • Si la taille de la charge utile est d'une taille maximale de 10 Mo autorisée, il est possible que la réponse est transmise dans un format compressé. Accéder à <ph type="x-smartling-placeholder"></ph> Cause: la taille de la charge utile de la réponse dépasse la limite autorisée après décompression.
4. Vérifier que la taille de la charge utile de la réponse est bien > la limite autorisée de 10 Mo en cochant la case la réponse réelle en procédant comme suit: <ph type="x-smartling-placeholder">
   </ph>
   1. Si vous n'avez pas accès à la requête réelle adressée au serveur cible/backend, puis accédez à Resolution (Résolution).
   2. Si vous avez accès à la requête réelle adressée au serveur cible/backend, procédez comme suit: <ph type="x-smartling-placeholder">
      </ph>
      1. Si vous êtes un utilisateur de cloud public/cloud privé, envoyez une requête directement à le serveur backend à partir du serveur backend lui-même ou de toute autre machine à partir de laquelle vous sont autorisés à envoyer la requête au serveur backend.
      2. Si vous êtes un utilisateur du Private Cloud, vous pouvez également envoyer une requête au de l'un des processeurs de messages.
      3. Vérifiez la taille de la charge utile transmise dans la réponse en vérifiant le En-tête Content-Length.
      4. Si vous constatez que la taille de la charge utile est supérieure à limite autorisée dans Apigee Edge, c'est la cause du problème 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, Content-Length: 11534336 (which is ~11 MB) est à l'origine de cette erreur, car il dépasse la valeur 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 si l'en-tête de réponse Content-Encoding est défini sur gzip, Apigee décompresse la réponse. charge utile. Pendant le processus de décompression, si Apigee trouve que la taille de la charge utile est supérieure supérieure à la limite autorisée dans Apigee Edge. 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 d'erreur et la taille de la charge utile de la réponse pour l'erreur observée à l'aide des journaux de surveillance des API, de l'outil Trace ou de NGINX Access, comme expliqué dans Étapes de diagnostic courantes pour le scénario 2.
2. Si la source de la défaillance a la valeur target, cela indique que le la taille de la charge utile envoyée par l'application cible/backend à Apigee est supérieure à 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 > une limite de 10 Mo autorisée, c'est la cause de l'erreur.
   • Si la taille de la charge utile est d'environ 10 Mo, il est possible que la charge utile de la réponse soit transmis au format compressé. Dans ce cas, vérifiez la taille non compressée du fichier la charge utile de réponse.
4. Vous pouvez vérifier si la réponse de la cible/du backend a été envoyée dans un format compressé et la taille non compressée était supérieure à la limite autorisée à l'aide de l'un des éléments suivants : méthodes:

   Trace

   À l'aide de l'outil Trace:

   1. Si vous avez capturé une trace pour la requête en échec, reportez-vous aux étapes détaillées dans Trace et <ph type="x-smartling-placeholder">
      </ph>
      1. Déterminez la valeur de target.received.content.length.
      2. Vérifiez si la requête du client contient les Encodage du contenu: en-tête gzip
   2. Si la valeur de target.received.content.length atteint environ 10 Mo autorisés. et l'en-tête de réponse Content-Encoding: gzip , nous obtenons 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 adressée au serveur cible/backend, puis accédez à Resolution (Résolution).
   2. Si vous avez accès à la requête réelle adressée au serveur cible/backend, procédez comme suit: <ph type="x-smartling-placeholder">
      </ph>
      1. Vérifiez la taille de la charge utile transmise dans la réponse avec le 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 la taille non compressée de la charge utile est supérieure à limite autorisée dans Apigee Edge, cela explique 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, mais la taille du fichier non compressé testzippedfile était ~ 15 Mo.

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

   Journaux de processeur de messages

   Utilisation des journaux du processeur de messages:

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

   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 concernant les erreurs HTTP 502.

   2. Vérifier les journaux du processeur de messages

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

   3. Effectuez une recherche pour voir s'il existe des erreurs 502 pendant une durée spécifique (si le problème s'est produit dans le passé) ou si des requêtes échouent encore 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 provenant de system.log semblables à celles ci-dessous. (TotalRead et chunkCount peuvent varier selon 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 le Le nombre total d'octets lus est > 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 soit supérieure à 10 Mo et qu'Apigee génère l'erreur lorsque la taille commence à dépasser la limite de 10 Mo avec le code d'erreur comme protocol.http.TooBigBody

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

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, telle qu'indiquée pour Request/response size dans Limites d'Apigee Edge

1. Si vous êtes un utilisateur de cloud public, la limite maximale de requêtes et de réponses la taille de la charge utile est celle indiquée pour Request/response size dans Limites d'Apigee Edge
2. Si vous êtes un utilisateur du Private Cloud , il est possible que vous ayez modifié le nombre maximal par défaut limite de taille de la charge utile des requêtes et des réponses (même s'il ne s'agit pas d'une pratique recommandée). Vous pouvez déterminer la taille maximale de la charge utile de requête en suivant les instructions dans Vérifier la limite actuelle

Comment vérifier la limite actuelle ?

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

Cette section explique comment vérifier que la propriété HTTPResponse.body.buffer.limit a été mis à jour avec une nouvelle valeur dans le message Processeurs.

1. Sur le 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éfini avec la valeur 10m dans http.properties

   Cela indique que la limite de taille de la charge utile de requête configurée dans Apigee pour Private Cloud correspond à 10 Mo.

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
• Commande curl complète utilisée pour reproduire l'erreur 502
• Fichier de suivi des requêtes API
• Sortie complète de la réponse de la cible/du serveur backend, ainsi que de 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 en échec
• Nom de l'organisation
• Nom de l'environnement
• Groupe de proxys d'API
• Fichier de suivi des requêtes API en échec
• Commande curl complète utilisée pour reproduire l'erreur 502
• Sortie complète de la réponse de la cible/du serveur backend, ainsi que de 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 les valeurs réelles.

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