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

413 Request Entity Too Large - 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 413 Request Entity Too Large 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 413 Request Entity Too Large

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 l'application cliente à Apigee Edge dans le cadre d'une requête 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 requête est supérieure à la limite autorisée	La taille de la charge utile envoyée par l'application cliente dans le cadre d'une requête HTTP adressée à Apigee Edge est supérieure à la limite autorisée dans Apigee Edge.	Utilisateurs Edge Public and Private Cloud
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 de la requête HTTP adressée à Apigee Edge dépasse la limite autorisée lorsqu'elle est décompressée par Apigee Edge.	Utilisateurs Edge Public and Private Cloud

Étapes de diagnostic courantes

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

Surveillance des API

Pour diagnostiquer l'erreur à l'aide de la surveillance des API:

Connectez-vous à l'interface utilisateur Apigee Edge en tant qu'utilisateur disposant du rôle approprié.
Accédez à l'organisation dans laquelle vous souhaitez examiner le problème.
Accédez à la page Analyze > API Monitoring > Investigate (Analyser > Surveillance des API > Enquêter).
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.
Tracez le code d'erreur par rapport à l'heure.
Sélectionnez une cellule contenant le code d'erreur protocol.http.TooBigBody et le code d'état 413, comme indiqué ci-dessous:
Les informations sur le code d'erreur protocol.http.TooBigBody s'affichent comme indiqué ci-dessous:
Cliquez sur Afficher les journaux, puis développez la ligne de la requête ayant échoué. Ensuite, dans la fenêtre Journaux, notez les détails comme indiqué ci-dessous :
Non compressé

Scénario 1: Demande de charge utile 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 a la valeur protocol.http.TooBigBody et la longueur de la requête est supérieure à 10 Mo, cela indique que la taille de la charge utile de la requête du client est supérieure à la limite autorisée dans Apigee.
Compressé

Scénario 2: Demande de charge utile 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 a la valeur protocol.http.TooBigBody et la longueur de la requête est inférieure à 10 Mo, cela indique que la taille de la charge utile de la requête du client est inférieure à la limite autorisée dans son format compressé, mais que 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 effectuez l'une des opérations suivantes :
- 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 l'erreur 413 Request Entity Too Large.
Assurez-vous que l'option Afficher tous les détails de 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: Demande de charge utile envoyée sous forme non compressée

Prenez note des informations suivantes:
- Content-Encoding:absent
- Content-Length: 15360204
Compressé

Scénario 2: Demande de charge utile envoyée sous forme compressée

Prenez note des informations suivantes:
- Content-Encoding:gzip
- Content-Length: 14969
- Type de contenu:application/x-gzip
Parcourez les différentes phases de la trace et localisez l'origine de l'échec.
L'erreur se produit généralement dans un flux après la phase Request Received from Client (Requête reçue du client) comme indiqué ci-dessous:
Notez la valeur de l'erreur dans la trace. L'exemple de trace ci-dessus montre :
- erreur:Body buffer overflow
- error.class::com.apigee.errors.http.user.RequestTooLarge
Accédez à Response Sent to Client (Réponse envoyée au client) et notez les valeurs de l'erreur à partir de la trace. 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"}}}
Dans la trace, accédez à la phase AX (Données analytiques enregistrées) et 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 :
- La taille réelle de la charge utile de la requête lorsqu'elle est envoyée dans un format non compressé et
- Taille de la charge utile de la requête après décompression par Apigee, lorsque la charge utile est envoyée dans un format compressé. Dans ce scénario, elle sera toujours identique à la valeur de la limite autorisée (10 Mo).
Remarque:L'en-tête d'erreur Content-Length peut indiquer la taille de la charge utile de l'erreur et non la charge utile de la requête. Pour cette erreur, nous devons prendre en compte la valeur spécifiée 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 dans les deux scénarios en fonction de la valeur de la variable client.received.content.length:

Scénario	Valeur de client.received.content.length	Motif de l'échec
Charge utile de la requête au format non compressé	Environ 15 Mo	Taille > limite autorisée de 10 Mo.
Charge utile de la requête au format compressé	Environ 10 Mo	Taille maximale dépassée en cas de décompression Remarque:La taille réelle de la charge utile après décompression peut être nettement supérieure à 10 Mo. Cependant, Apigee arrête la décompression dès que la taille des données non compressées 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, procédez comme suit:

Si vous êtes un utilisateur du cloud privé, vous pouvez utiliser les journaux d'accès NGINX pour déterminer les informations essentielles 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

Remarque:Remplacez ORG, ENV et PORT# par des valeurs réelles.
Recherchez s'il existe des erreurs 413 pendant une durée spécifique (si le problème s'est déjà produit par le passé) ou si des requêtes échouent toujours avec 413.

Si vous trouvez des erreurs 413 avec le X-Apigee-fault-code correspondant à la valeur de X-Apigee-fault-code , déterminez la valeur de la source X-Apigee-fault-code .

Non compressé

Scénario 1 : Demander la taille de la charge utile 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 > limite autorisée).

Compressé

Scénario 2 : Demander la taille de la charge utile dans un format 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-source	`policy`

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

Dans ce scénario, Apigee Edge renvoie 413 même si la longueur de la requête est inférieure à la limite autorisée, car la requête peut avoir été envoyée dans un format compressé et la taille de la charge utile dépasse la limite 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 de l'erreur et la taille de la charge utile de la requête pour l'erreur observée à l'aide des journaux d'accès de surveillance d'API, de Trace Tool ou de NGINX, comme expliqué dans la section Étapes de diagnostic courantes avec le scénario 1 (non compressé).
Si la source d'erreur a la valeur policy ou proxy, cela indique que la taille de la charge utile de la 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 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 inférieure à la limite autorisée de 10 Mo, il est possible que la charge utile de la requête soit transmise dans un format compressé. Consultez Cause: la taille de la charge utile de la requête dépasse la limite autorisée après la décompression.
Vous pouvez également vérifier si la taille de la charge utile de la requête est effectivement supérieure à la limite autorisée de 10 Mo en vérifiant la requête réelle en procédant comme suit :
1. Si vous n'avez pas accès à la requête réelle envoyée par l'application cliente, passez à la section Résolution.
2. Si vous avez accès à la requête réelle envoyée par l'application cliente, procédez comme suit :
  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 dépasse la limite autorisée dans Apigee Edge, c'est la cause du problème.

Ré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 que l'en-tête de requête Content-Encoding est défini sur gzip, Apigee décompresse la charge utile de la requête. Au cours du processus de décompression, si Apigee détermine que la taille de la charge utile est supérieure à 10 Mo, la limite autorisée, il arrête la décompression et répond immédiatement avec 413 Request Entity Too Large avec le code d'erreur protocol.http.TooBigBody.

Diagnostic

Déterminez le code d'erreur, la source de l'erreur et la taille de la charge utile de la requête de l'erreur observée à l'aide des journaux d'accès Surveillance, Trace Tool ou NGINX Access, comme expliqué dans la section Étapes de diagnostic courantes avec le scénario 2 (compressé).
Si la source d'erreur a la valeur policy ou proxy, cela indique que la taille de la charge utile de la 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 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 inférieure à la limite autorisée de 10 Mo, il est possible que la charge utile de la requête soit transmise dans un format compressé. Dans ce cas, vérifiez la taille non compressée de la charge utile de la 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 taille non compressée était supérieure à la limite autorisée à l'aide de l'une des méthodes suivantes:
Trace

Pour valider à l'aide de l'outil Trace:
1. Si vous avez capturé une trace de la requête ayant échoué, reportez-vous aux étapes détaillées dans Trace et
  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 .
2. Si la valeur de la variable client.received.content.length est supérieure aux 10 Mo, à la limite autorisée et à l'en-tête de requête client.received.content.length , c'est la cause de cette erreur.
Demande réelle

Pour valider à 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, passez à la section Résolution.
2. Si vous avez accès à la requête réelle envoyée par l'application cliente, procédez comme suit :
  1. Vérifiez la taille de la charge utile transmise dans la requête, ainsi que l'en-tête Content-Encoding envoyé dans la requête.
  2. Vérifiez si la taille non compressée de la charge utile dépasse la 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 autorisée. Toutefois, 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 envoyée et savoir si l'en-tête Content-Encoding est défini sur gzip.
Journaux du processeur de messages

Pour valider à l'aide des journaux du processeur de messages:

Remarque:Les instructions de cette section sont destinées 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. Recherchez s'il existe des erreurs 413 pendant une durée spécifique (si le problème s'est produit par 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 trouverez des lignes de system.log semblables à ce qui suit (TotalRead et chunkCount peuvent varier dans 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. 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 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 un code d'erreur de protocol.http.TooBigBody
  
  Remarque:La ligne ci-dessus apparaît dans les journaux du processeur de messages, même si vous envoyez la charge utile de la requête dans un format non compressé. La seule différence est que TotalRead contiendra la taille réelle de la charge utile de la requête dans ce scénario.

Résolution

Corriger la taille

Option 1 [recommandée]: corriger l'application cliente afin de ne pas envoyer de charge utile supérieure à la limite autorisée

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

Dans l'exemple décrit 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 indiqué ci-dessous :
```
curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
```
Si vous souhaitez envoyer une requête/charge utile au-delà de la limite autorisée, passez aux options suivantes.

Format d'URL signé

Option 2 [recommandée]: utiliser un format d'URL signées dans un élément Apigee JavaCallout

Pour les charges utiles supérieures à 10 Mo, Apigee recommande d'utiliser un modèle d'URL signées dans Apigee JavaCallout, illustré par l'exemple Edge Callout: 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 le streaming dans Apigee.

CwC

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

Cette option ne doit être utilisée que lorsque vous ne pouvez utiliser aucune des options recommandées, car des problèmes de performances peuvent se produire si la taille par défaut est augmentée.

Apigee fournit une propriété CwC qui lui permet d'augmenter la taille limite de la charge utile des requêtes et des réponses. Pour en savoir plus, consultez 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, comme indiqué pour Request/response size dans Limites Apigee Edge.

Si vous êtes un utilisateur de cloud public, la limite maximale de taille des charges utiles de requête et de réponse est indiquée pour Request/response size dans Limites Apigee Edge.
Si vous êtes un utilisateur du cloud privé , vous avez peut-être modifié la limite 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é HTTPRequest.body.buffer.limit a été mise à jour avec une nouvelle valeur sur les processeurs de messages.

Sur la machine du 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 qui a été définie à l'aide de la commande suivante :
```
grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
```

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

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

Dans l'exemple de sortie ci-dessus, notez que la propriété HTTPRequest.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 d'aide de l'assistance Apigee, consultez la section 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 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 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 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 des 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

Problème constaté

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

Ré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 du processeur de messages

Résolution

Corriger la taille

Format d'URL signé

Streaming

CwC

Limites

Comment vérifier la limite actuelle ?

Vous devez collecter des informations de diagnostic