Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

413 Request Entity Too Large - 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 413 Request Entity Too Large 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 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 à Apigee Edge est supérieure à la limite autorisée dans Apigee Edge.	Utilisateurs du cloud public et privé Edge
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 d'une requête HTTP à Apigee Edge est supérieure à la limite autorisée lorsqu'elle est décompressée par Apigee Edge.	Utilisateurs du cloud public et privé Edge

Étapes de diagnostic courantes

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

Surveillance des API

Pour diagnostiquer l'erreur à l'aide d'API Monitoring :

Connectez-vous à l'UI Apigee Edge en tant qu'utilisateur disposant d'un rôle approprié.
Basculez vers l'organisation dans laquelle vous souhaitez examiner le problème.
Accédez à la page Analyser > API Monitoring > 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 graphiquement Code d'erreur par rapport à 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 suit :
Cliquez sur Afficher les journaux, puis développez la ligne correspondant à la demande ayant échoué. Ensuite, dans la fenêtre Journaux, notez les détails comme indiqué ci-dessous :
Non compressé

Scénario 1 : Données utiles de la requête envoyées sous forme non compressée

Dans la fenêtre "Journaux", notez les détails suivants :
- Code d'état : 413
- Source de la défaillance : proxy
- Code d'erreur : protocol.http.TooBigBody.
- Longueur de la requête(en octets) : 15360440 (environ 15 Mo)
Si la source de l'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 requête HTTP du client a une taille de charge utile supérieure à la limite autorisée dans Apigee.
Compressé

Scénario 2 : Données utiles de la requête envoyées sous forme compressée

Dans la fenêtre Journaux, notez les informations suivantes :
- Code d'état : 413
- Source de la défaillance : proxy
- Code d'erreur : protocol.http.TooBigBody.
- Longueur de la requête(en octets) : 15264 (~15 ko)
Si la source de l'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 HTTP 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 et l'une des options suivantes :
- Attendez que l'erreur 413 Request Entity Too Large se produise.
- 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 toutes les infos sur le flux est activée.
Sélectionnez l'une des requêtes ayant échoué et examinez la trace.
Accédez à la phase Demande reçue du client.
Non compressé

Scénario 1 : Données utiles de la requête envoyées sous forme non compressée

Notez les informations suivantes :
- Content-Encoding : absent
- Content-Length : 15360204
Compressé

Scénario 2 : Données utiles de la requête envoyées sous forme compressée

Notez les informations suivantes :
- Content-Encoding : gzip
- Content-Length : 14969
- Content-Type : application/x-gzip
Parcourez les différentes phases de la trace et identifiez l'emplacement de l'échec.
Vous trouverez généralement l'erreur dans un flux après la phase Requête reçue du client, comme indiqué ci-dessous :
Notez la valeur de l'erreur à partir de la trace. L'exemple de trace ci-dessus montre :
- Erreur : Body buffer overflow
- error.class: : com.apigee.errors.http.user.RequestTooLarge
Accédez à 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"}}}
Accédez à la phase AX (données Analytics enregistrées) dans la trace, puis cliquez dessus.
Dans la section Détails de la phase, faites défiler la page jusqu'à Variables lues.
Déterminez la valeur de la variable client.received.content.length , qui indique :
- Taille réelle de la charge utile de la requête lorsqu'elle est envoyée au format non compressé
- Taille de la charge utile de la requête après décompression par Apigee, lorsque la charge utile est envoyée au format compressé. Dans ce scénario, elle sera toujours égale à la valeur de la limite autorisée (10 Mo).
Remarque : Il peut y avoir un en-tête d'erreur Content-Length qui indique la taille de la charge utile d'erreur et non celle de la charge utile de la requête. Pour cette erreur, nous devons tenir compte de la valeur spécifiée dans la variable client.received.content.length .

Non compressé

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

Variable client.received.content.length : 15360204

Compressé

Scénario 2 : Charge utile de la requête au 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é	~15 Mo	La taille du fichier dépasse la limite autorisée de 10 Mo.
Charge utile de la requête au format compressé	~10 Mo	Taille limite dépassée après décompression Remarque : La taille réelle de la charge utile après décompression peut être bien supérieure à 10 Mo. Toutefois, 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 :

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

Remarque : Remplacez ORG, ENV et PORT# par des valeurs réelles.
Recherchez les éventuelles erreurs 413 sur une période spécifique (si le problème s'est produit dans le passé) ou les requêtes qui échouent encore avec 413.

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

Non compressé

Scénario 1 : Taille de la charge utile de requête au format non 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-source :

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 : Taille de la charge utile de requête au 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-source :

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 la longueur de la requête est inférieure à la limite autorisée, car la requête peut avoir été envoyée au format compressé et la taille de la charge utile dépasse la limite après 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 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 1 (non compressé).
Si la source de l'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 des données utiles de requête 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 inférieure à la limite autorisée de 10 Mo, il est possible que la charge utile de la requête soit transmise au format compressé. Accéder à 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 effectivement supérieure à la limite autorisée de 10 Mo en vérifiant la requête réelle en suivant les étapes ci-dessous :
1. Si vous n'avez pas accès à la demande réelle effectuée par l'application cliente, accédez à Résolution.
2. Si vous avez accès à la demande réelle effectué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 est supérieure à la limite autorisée dans Apigee Edge, il s'agit de 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 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. Si, lors de la décompression, Apigee constate 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 et 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 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 (compressé).
Si la source de l'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 des données utiles de requête 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 inférieure à la limite autorisée de 10 Mo, il est possible que la charge utile de la requête soit transmise au 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 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

Pour valider à l'aide de 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éterminer la valeur de la variable client.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 la variable client.received.content.length est supérieure à 10 Mo, la limite autorisée, et que l'en-tête de requête Content-Encoding: gzip est présent, il s'agit de la cause de cette erreur.
Demande réelle

Pour valider les résultats à l'aide de la requête réelle :
1. Si vous n'avez pas accès à la demande réelle effectuée par l'application cliente, accédez à Résolution.
2. Si vous avez accès à la demande réelle effectué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 est supérieure à la limite autorisée dans Apigee Edge.
    
    Exemple de demande :
    
    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, mais 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, obtenez les journaux du client pour connaître la taille de la charge utile envoyée et vérifier 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 ne concernent que les utilisateurs d'Edge pour le cloud privé.
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 413.
2. Vérifiez les journaux du processeur de messages :
  
  /opt/apigee/var/log/edge-message-processor/logs/system.log
3. Recherchez les éventuelles erreurs 413 sur une période spécifique (si le problème s'est produit dans le passé) ou les requêtes qui é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 à celles ci-dessous (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. Pendant le 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 signifie 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.
  
  Remarque : La ligne ci-dessus s'affiche dans les journaux du processeur de messages, même si vous envoyez la charge utile de la requête au 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.

Solution

Taille fixe

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

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

Dans l'exemple ci-dessus, vous pouvez résoudre le problème en transmettant une charge utile de taille inférieure, par exemple test5mbfile (avec une taille de 5 Mo), comme indiqué ci-dessous :
```
curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
```
Si vous le souhaitez et que vous voulez envoyer une requête/charge utile au-delà de la limite autorisée, passez aux options suivantes.

Format d'URL signée

Option 2 [recommandée]: Utiliser un modèle d'URL signée dans un appel Java Apigee

Pour les charges utiles supérieures à 10 Mo, Apigee recommande d'utiliser un modèle d'URL signé dans un appel Java Apigee, illustré par l'exemple Appel de service Edge : Générateur d'URL signée 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 : Utilisez la propriété CwC pour augmenter la limite du tampon

Cette option ne doit être utilisée que si vous ne pouvez pas utiliser l'une des options recommandées, car des problèmes de performances peuvent survenir si la taille par défaut est augmentée.

Apigee fournit une propriété CwC 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 Définir la taille maximale 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 charges utiles dont la taille dépasse la limite autorisée, comme indiqué pour Request/response size dans Limites d'Apigee Edge.

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.
Si vous êtes un utilisateur de Private Cloud , vous avez peut-être modifié la limite 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é HTTPRequest.body.buffer.limit a été mise à jour avec une nouvelle valeur sur les processeurs de messages.

Sur la machine 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 de la commande suivante :
```
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é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 413
Fichier de trace pour les requêtes API

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

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

Solution

Taille fixe

Format d'URL signée

Streaming

CwC

Limites

Comment vérifier la limite actuelle ?

Vous devez collecter des informations de diagnostic