Cette page a été traduite par l'API Cloud Translation.

413 Request Entity Too Large - 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 reçoit le code d'état HTTP 413 Request Entity Too Large avec le code d'erreur protocol.http.TooBigBody comme réponse aux appels d'API.

Message d'erreur

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

HTTP/1.1 413 Request Entity Too Large

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 l'application cliente à Apigee Edge dans le cadre de La requête HTTP dépasse 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 requête est supérieure à la limite autorisée	La taille de la charge utile envoyée par l’application cliente dans le cadre de la requête HTTP à Apigee Edge est dépasse la limite autorisée dans Apigee Edge.	Utilisateurs Edge de cloud public et privé
La taille de la charge utile de la requête dépasse la limite autorisée après décompression	La taille de la charge utile envoyée au format compressé par l'application cliente dans le cadre du protocole HTTP envoyée à Apigee Edge est supérieure à la limite autorisée lors de sa décompression par Apigee Edge.	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

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

<ph type="x-smartling-placeholder"></ph> Connectez-vous à l'interface utilisateur d'Apigee Edge en tant qu'utilisateur disposant d'un rôle approprié.
Passez à l'organisation dans laquelle vous souhaitez examiner le problème
Accédez à Analyser > Surveillance des API > Examiner.
Sélectionnez la période spécifique au cours de laquelle vous avez observé les erreurs.
Vous pouvez sélectionner le filtre Proxy pour affiner le code d'erreur.
Représentez le code d'erreur par rapport à l'heure.
Sélectionnez une cellule avec le code d'erreur protocol.http.TooBigBody et Code d'état 413tel qu'indiqué ci-dessous:
Les informations sur le code d'erreur protocol.http.TooBigBody s'affichent sous la forme comme indiqué ci-dessous:
Cliquez sur Afficher les journaux et développez la ligne correspondant à la requête ayant échoué. Ensuite, à partir de Logs (Journaux), notez les détails comme indiqué ci-dessous :
Non compressé

Scénario 1: Charge utile de requête envoyée sous forme non compressée

Dans la fenêtre "Journaux", notez les informations suivantes:
- Code d'état:413
- Source de l'erreur:proxy
- Code d'erreur:protocol.http.TooBigBody.
- Longueur de la requête(octets) : 15360440 (~15 Mo)
Si la Source d'erreur a la valeur proxy , le Code d'erreur prend la valeur protocol.http.TooBigBody, et la valeur Request Length (longueur de la requête) dépasse 10 Mo, cela indique que la requête HTTP du client comporte un une taille de charge utile de requête supérieure à la limite autorisée dans Apigee.
Compressé

Scénario 2: Charge utile de requête envoyée sous forme compressée

Dans la fenêtre Journaux, notez les détails suivants:
- Code d'état:413
- Source de l'erreur:proxy
- Code d'erreur:protocol.http.TooBigBody.
- Longueur de la requête(octets) : 15264 (~15 Ko)
Si la Source d'erreur a la valeur proxy , le Code d'erreur est associé à la valeur protocol.http.TooBigBody et la longueur de la requête est inférieure à 10 Mo, cela indique que la requête HTTP du client comporte la taille de la charge utile de la requête est inférieure à la limite autorisée dans son format compressé, mais la taille de la charge utile est supérieure à la limite autorisée lorsqu'elle est décompressée par Apigee.

Trace

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

Activez la session de trace, puis <ph type="x-smartling-placeholder">
- Attendez que l'erreur 413 Request Entity Too Large se produise ou
- Si vous pouvez reproduire le problème, effectuez l'appel d'API et reproduisez les actions 413 Request Entity Too Large erreur
Assurez-vous que l'option Show all Flow Infos (Afficher toutes les informations sur le flux) est activée.
Sélectionnez l'une des requêtes ayant échoué et examinez la trace.
Accédez à la phase Request Received from Client (Demande reçue du client).
Non compressé

Scénario 1: Charge utile de requête envoyée sous forme non compressée

Notez les informations suivantes:
- Content-Encoding:absent
- Longueur du contenu:15360204
Compressé

Scénario 2: Charge utile de requête envoyée sous forme compressée

Notez les informations suivantes:
- Content-Encoding (Encodage du contenu) : gzip
- Longueur du contenu:14969
- Content-Type (Type de contenu) : application/x-gzip
Parcourez les différentes phases de la trace et localisez l'origine de l'échec.
L'erreur apparaît généralement dans un flux après la demande reçue de Client, comme indiqué ci-dessous:
Notez la valeur de l'erreur à partir de la trace. L'exemple de trace ci-dessus montre: <ph type="x-smartling-placeholder">
- erreur:Body buffer overflow
- error.class::com.apigee.errors.http.user.RequestTooLarge
Accédez à Response Sent to Client (Réponse envoyée au client), puis notez les valeurs de l'erreur à partir du traceur. L'exemple de trace ci-dessous montre:
- erreur:413 Request Entity Too Large
- Contenu de l'erreur: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
Accédez à la phase AX (Données analytiques enregistrées) dans la trace, puis cliquez dessus.
Dans la section Phase Details (Détails de la phase), faites défiler la page jusqu'à Variables Read (Lecture des variables).
Déterminez la valeur de la variable client.received.content.length , qui indique: <ph type="x-smartling-placeholder">
- La taille réelle de la charge utile de la requête lorsqu'elle est envoyée dans un format non compressé et
- La taille de la charge utile de la requête après décompression par Apigee, lorsque la charge utile est envoyées au format compressé. Elle est toujours identique à la valeur de l'attribut autorisé (10 Mo) dans ce scénario.
<ph type="x-smartling-placeholder">
</ph> Remarque:Il se peut que l'en-tête d'erreur Content-Length indique la taille de la d'erreur et non la charge utile de la requête. Pour cette erreur, nous devons considérer la valeur spécifié dans la variable client.received.content.length .

Non compressé

Scénario 1: Demander la charge utile sous forme non compressée

Variable client.received.content.length: 15360204

Compressé

Scénario 2: Demander la charge utile dans un format compressé

Variable client.received.content.length: 10489856

Le tableau suivant explique pourquoi l'erreur 413 est renvoyée par Apigee sous les deux scénarios basés sur la valeur de la variable client.received.content.length:

Scénario	Valeur de client.received.content.length	Motif de l'échec
Charge utile de requête dans un format non compressé	Environ 15 Mo	Taille > limitée à 10 Mo.
Charge utile de requête dans un format compressé	Environ 10 Mo	Taille maximale dépassée lors de la décompression <ph type="x-smartling-placeholder"> </ph> Remarque:La taille réelle de la charge utile après décompression peut être bien supérieure à 10 Mo. Cependant, Apigee arrête la décompression dès que la taille du fichier dépasse la limite de 10 Mo (limite par défaut) et renvoie l'erreur.

NGINX

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

Si vous êtes un utilisateur Private Cloud, vous pouvez utiliser les journaux d'accès NGINX pour déterminer les informations clés sur les erreurs HTTP 413.
Vérifiez les journaux d'accès NGINX:

/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
<ph type="x-smartling-placeholder">
</ph> Remarque:Remplacez ORG, ENV et PORT# par des valeurs réelles.
Effectuez une recherche pour voir s'il existe des erreurs 413 pendant une période spécifique (si si le problème s'est produit dans le passé) ou si des requêtes échouent encore 413

Si vous trouvez des erreurs 413 avec la correspondance X-Apigee-fault-code la valeur de protocol.http.TooBigBody, puis déterminez la valeur de la X-Apigee-fault-source.

Non compressé

Scénario 1 : Taille de la charge utile de requête dans un format non compressé

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	`protocol.http.TooBigBody`
X-Apigee-fault-sourc	`policy`

Notez la longueur de la requête:15360440 (14,6 Mo > la limite autorisée).

Compressé

Scénario 2 : Taille de la charge utile de requête dans un format compressé

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	`protocol.http.TooBigBody`
X-Apigee-fault-source	`policy`

Notez la longueur de la requête:15264 (14,9 Ko < limite autorisée).

Dans ce scénario, Apigee Edge renvoie 413 même si le La durée de la requête est inférieure à la limite autorisée, car il se peut ont été envoyées dans un format compressé et la taille de la charge utile dépasse la lors de la décompression par Apigee Edge.

Cause: la taille de la charge utile de la requête est supérieure à la limite autorisée

Diagnostic

Déterminez le code d'erreur, la source d'erreur et la taille de la charge utile de la requête pour erreur observée à l'aide des journaux d'accès de l'API Monitoring, de l'outil Trace ou de NGINX, comme expliqué dans Étapes de diagnostic courantes avec le scénario 1 (non compressé).
Si la source de la défaillance a la valeur policy ou proxy, alors indique que la taille de la charge utile de requête envoyée par l'application cliente à Apigee est supérieure à la limite autorisée dans Apigee Edge.
Vérifiez la taille de la charge utile de la requête telle qu'elle est 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 < autorisée à 10 Mo, il est possible que la demande est transmise dans un format compressé. Accédez à la page Cause: la taille de la charge utile de la requête dépasse la limite autorisée après décompression
Vous pouvez également vérifier si la taille de la charge utile de la requête est > 10 Mo autorisés par en vérifiant la requête réelle en procédant comme suit: <ph type="x-smartling-placeholder">
1. Si vous n'avez pas accès à la requête réelle envoyée par l'application cliente, accédez à Résolution.
2. Si vous avez accès à la requête proprement dite effectuée par l'application cliente, exécutez la en suivant les étapes ci-dessous: <ph type="x-smartling-placeholder">
  1. Vérifiez la taille de la charge utile transmise dans la requête.
  2. Si vous constatez que la taille de la charge utile est supérieure à celle du limite autorisée dans Apigee Edge, c'est la cause du problème.

Solution

Accédez à Résolution.

Cause: la taille de la charge utile de la requête dépasse la limite autorisée après décompression

Si la charge utile de la requête est envoyée au format compressé et si l'en-tête de requête Content-Encoding est défini sur gzip, Apigee décompresse la requête charge utile. Pendant le processus de décompression, si Apigee trouve que la taille de la charge utile est supérieure de plus de 10 Mo, <ph type="x-smartling-placeholder"></ph> limite autorisée, il arrête ensuite la décompression et répond immédiatement avec 413 Request Entity Too Large avec le code d'erreur protocol.http.TooBigBody

Diagnostic

Déterminer le code d'erreur, la source de défaut et la taille de la charge utile de la requête 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 avec le scénario 2 (compressé).
Si la source de la défaillance a la valeur policy ou proxy, alors cela indique que la taille de la charge utile de requête envoyée par l'application cliente à Apigee est supérieure supérieure à la limite autorisée dans Apigee Edge.
Vérifiez la taille de la charge utile de la requête comme déterminé à 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 < autorisée à 10 Mo, il est possible que la demande est transmise dans un format compressé. Dans ce cas, vérifiez la taille non compressée du fichier charge utile de requête compressée.
Vous pouvez vérifier si la requête du client a été envoyée dans un format compressé et si la la taille non compressée était supérieure à la limite autorisée à l'aide de l'un des éléments suivants méthodes:
Trace

Pour valider à 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">
  1. Déterminer la valeur de la variable client.received.content.length
  2. Vérifiez si la requête du client contient l'en-tête Content-Encoding: gzip en-tête
2. Si la valeur de la variable client.received.content.length est supérieure à la 10 Mo, <ph type="x-smartling-placeholder"></ph> la limite autorisée et l'en-tête de requête Content-Encoding: gzip, c'est la cause de l'erreur.
Demande réelle

Pour effectuer la validation à l'aide de la requête réelle:
1. Si vous n'avez pas accès à la requête réelle envoyée par l'application cliente, accédez à Résolution.
2. Si vous avez accès à la requête proprement dite effectuée par l'application cliente, exécutez la en suivant les étapes ci-dessous: <ph type="x-smartling-placeholder">
  1. Vérifiez la taille de la charge utile transmise dans la requête avec le En-tête Content-Encoding envoyé dans la requête.
  2. Vérifiez si la taille non compressée de la charge utile est supérieure à limite autorisée dans Apigee Edge
    
    Exemple de requête:
    
    curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v
    
    Dans le cas ci-dessus, la taille du fichier test15mbfile.gz est inférieure à la limite de taille. la taille du fichier non compressé test15mbfile est d'environ 15 Mo et l'en-tête Content-Encoding est gzip.
    
    Si vous utilisez un autre client, récupérez les journaux client pour connaître la taille de la charge utile en cours d'envoi et si l'en-tête Content-Encoding est défini sur gzip.
Journaux de processeur de messages

Pour valider l'utilisation des journaux du processeur de messages:
<ph type="x-smartling-placeholder">
</ph> Remarque:Les instructions de cette section s'adressent uniquement aux utilisateurs de cloud privé Edge.
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 413.
2. Vérifiez 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 413 pendant une période spécifique (si les qui s'est produit dans le passé) ou si des requêtes échouent toujours avec 413.
  
  Vous pouvez utiliser les chaînes de recherche suivantes:
```
grep -ri "chunkCount"
```
```
grep -ri "RequestTooLarge"
```
4. Vous verrez des lignes provenant de system.log semblables à ce qui suit (TotalRead et chunkCount peuvent varier selon votre cas):
```
2021-07-06 13:29:57,544  NIOThread@1 ERROR HTTP.SERVICE -
  TrackingInputChannel.checkMessageBodyTooLarge()
  : Message is too large.  TotalRead 10489856 chunkCount 2570

2021-07-06 13:29:57,545  NIOThread@1 INFO  HTTP.SERVICE -
  ExceptionHandler.handleException()
  : Exception trace: com.apigee.errors.http.user.RequestTooLarge
  : Body buffer overflow
```
5. Pendant le processus de décompression, dès que le processeur de messages détermine le total octets lus est > 10 Mo, il s'arrête et affiche la ligne suivante:
```
Message is too large.  TotalRead 10489856 chunkCount 2570
```
  Cela implique que la taille de la charge utile de la requête est supérieure à 10 Mo et qu'Apigee génère L'erreur RequestTooLarge lorsque la taille commence à dépasser la limite de 10 Mo avec le code d'erreur protocol.http.TooBigBody
  <ph type="x-smartling-placeholder">
  </ph> Remarque:La ligne ci-dessus apparaît dans les journaux du processeur de messages, même si vous envoyez le de la requête dans un format non compressé. La seule différence est que TotalRead contient la taille réelle de la charge utile de la requête dans ce scénario.

Solution

Corriger la taille

Option 1 [recommandée]: corrigez l'application cliente pour qu'elle n'envoie pas de charge utile supérieure à la taille limite autorisée

Analyser la raison pour laquelle le client spécifique envoie une demande / taille de charge utile supérieure à la limite autorisée telle que définie dans la section Limites.
Si ce n'est pas souhaitable, modifiez votre application cliente de sorte qu'elle envoie une requête / charge utile. inférieure à la limite autorisée.

Dans l'exemple discuté ci-dessus, vous pouvez résoudre le problème en transmettant un fichier de plus petite taille, par exemple la charge utile test5mbfile (avec une taille de 5 Mo), comme illustré ci-dessous:
```
curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
```
Si c'est souhaitable et que vous souhaitez envoyer une requête/charge utile au-delà de la limite autorisée, accédez à les options suivantes.

Format d'URL signé

Option 2 [recommandée]: Utilisez le format d'URL signée dans un élément JavaCall d'Apigee

Pour les charges utiles supérieures à 10 Mo, Apigee recommande d'utiliser un format d'URL signée au sein d'une Apigee JavaAccroche, illustré par le <ph type="x-smartling-placeholder"></ph> Exemple d'accroche Edge: Signed URL Generator, sur GitHub.

Streaming

Option 3 : Utiliser le streaming

Si votre proxy d'API doit gérer des requêtes et/ou des réponses très volumineuses, vous pouvez activer streaming dans Apigee.

CwC

Option 4 : Utiliser la propriété CwC pour augmenter la limite de la mémoire tampon

N'utilisez cette option que si vous ne pouvez utiliser aucune des options recommandées, car il pourrait des problèmes de performances si la taille par défaut est augmentée.

Apigee propose CwC, ce qui lui permet d'augmenter la limite de taille de la charge utile des requêtes et des réponses. Pour en savoir plus, consultez <ph type="x-smartling-placeholder"></ph> Définir la limite de taille des messages sur le routeur ou le processeur de messages

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

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
Si vous êtes un utilisateur du Private Cloud , il est possible que vous ayez modifié le paramètre 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 ?

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

Sur le processeur de messages, recherchez la propriété HTTPRequest.body.buffer.limit dans le répertoire /opt/apigee/edge-message- processor/conf et vérifiez la valeur définie à l'aide du code suivant : :
```
grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
```

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

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

Dans l'exemple de résultat ci-dessus, notez que la propriété HTTPRequest.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 for Private Cloud correspond à 10 Mo.

Si vous avez encore besoin de l'aide de l'assistance Apigee, accédez à Obligation de 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 413
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'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 413
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

413 Request Entity Too Large - TooBigBody

Symptôme

Message d'erreur

Causes possibles

Étapes de diagnostic courantes

Surveillance des API

Non compressé

Compressé

Trace

Non compressé

Compressé

Non compressé

Compressé

NGINX

Non compressé

Compressé

Cause: la taille de la charge utile de la requête est supérieure à la limite autorisée

Diagnostic

Solution

Cause: la taille de la charge utile de la requête dépasse la limite autorisée après décompression

Diagnostic

Trace

Demande réelle

Journaux de processeur de messages

Solution

Corriger la taille

Format d'URL signé

Streaming

CwC

Limites

Comment vérifier la limite actuelle ?

Vous devez collecter des informations de diagnostic