HTTP 413 Content Too Large : signification et solutions

Ce que signifie cette erreur et comment la reconnaître

• Un navigateur, un client API, un outil d’envoi ou une vérification de monitoring reçoit HTTP 413 Content Too Large.
• L’erreur apparaît lors de l’envoi d’un fichier volumineux, d’un formulaire, d’un document JSON, d’une requête multipart ou d’un autre corps de requête.
• Une version plus petite de la même requête peut réussir alors que la requête plus volumineuse échoue.
• La réponse peut provenir d’un proxy, d’un CDN, d’un WAF, d’un serveur web ou de l’application. Ses en-têtes ou son contenu peuvent varier selon la couche concernée.
• Le reste du site peut rester disponible et les URL ou types de requêtes sans rapport peuvent continuer à fonctionner.
• La résolution DNS et TLS peuvent rester saines, car 413 est une réponse de la couche HTTP.

Causes principales, classées par probabilité

1. La requête dépasse une limite de taille d’envoi ou de corps. L’application ou le serveur web peut imposer une taille maximale pour le corps de la requête, les fichiers, les formulaires ou les requêtes multipart.
2. Un intermédiaire impose une limite inférieure. Un reverse proxy, un CDN, un load balancer ou un WAF peut rejeter la requête avant que l’application d’origine ne la reçoive.
3. La requête est acheminée vers un endpoint plus strict. Des URL, méthodes, virtual hosts ou environnements différents peuvent appliquer des politiques de taille différentes.
4. Les limites de configuration ne correspondent pas. Le proxy peut autoriser une requête que l’application rejette, ou l’application peut en autoriser une que le proxy bloque.
5. La requête est involontairement plus volumineuse que prévu. La surcharge multipart, un champ encodé trop volumineux, une pièce jointe ou une nouvelle tentative du client avec des données dupliquées peuvent augmenter la taille du corps.
6. L’endpoint rejette intentionnellement les contenus volumineux. Certaines API ou routes d’envoi imposent une limite produit ou de sécurité qui ne doit pas être supprimée sans confirmer la politique prévue.

Comment corriger le problème

Pour les visiteurs et les utilisateurs d’API

1. Confirmez l’URL exacte et répétez la requête une seule fois, sans actualiser la page de manière répétée.
2. Si vous envoyez un fichier, essayez un fichier plus petit ou réduisez sa taille à l’aide d’un format ou d’une méthode de compression approuvé.
3. Pour une requête API, comparez le payload en échec avec un payload minimal valide. Vérifiez la présence de champs exceptionnellement volumineux, de données intégrées, de contenu dupliqué ou d’une construction multipart incorrecte.
4. Vérifiez que la requête utilise la méthode et le type de contenu prévus. Ne supprimez pas les contrôles d’authentification ou de sécurité pour contourner l’erreur.
5. Si les petites requêtes fonctionnent mais que la requête nécessaire échoue, envoyez au propriétaire du site l’URL, la méthode, la taille approximative de la requête, l’horodatage, les en-têtes de réponse et une description assainie du payload. Ne partagez pas de mots de passe, cookies, tokens ni secrets d’API.

Pour les propriétaires de sites et les développeurs

1. Capturez la requête en échec. Notez l’URL, la méthode HTTP, le type de contenu, la taille approximative du corps, le statut, les en-têtes de réponse et le passage éventuel par un proxy, un CDN, un load balancer ou un WAF. Masquez les identifiants et les données personnelles.
2. Reproduisez le problème en comparant les tailles. Testez une requête minimale valide et des requêtes progressivement plus volumineuses, ou comparez un envoi réussi avec celui qui échoue. Cela permet d’établir la limite effective sans modifier prématurément la configuration.
3. Identifiez la couche génératrice. Comparez le corps de la réponse, les en-têtes, les journaux d’accès, les journaux du proxy, les événements du WAF et les journaux de l’application pour le même horodatage et la même requête. Si la requête est absente des journaux de l’application, un composant en amont l’a peut-être rejetée en premier.
4. Comparez les limites sur le chemin. Vérifiez les limites pertinentes du corps de la requête, des envois, des requêtes multipart, du proxy, du CDN, du WAF et de l’application. La limite effective est contrôlée par le premier composant qui refuse la requête.
5. Choisissez la correction la plus ciblée. Si la requête doit être acceptée, ajustez uniquement la route ou le composant concerné après avoir confirmé l’autorisation ainsi que les implications en matière de mémoire, de stockage, de délai d’expiration et de sécurité. Si la limite est intentionnelle, conservez-la et modifiez le workflow client ou documentez le maximum pris en charge.
6. Retestez le schéma de requête d’origine. Utilisez la même méthode, la même URL, le même type de contenu et une taille de payload représentative. Vérifiez qu’une requête acceptée atteint l’application et que les requêtes malformées ou clairement trop volumineuses continuent d’être traitées comme prévu.
7. Vérifiez les comportements connexes. Testez une requête plus petite, une route sans rapport, le comportement de l’authentification ainsi que les autres niveaux de proxy ou d’application affectés par la modification de configuration. Conservez la modification sous contrôle de version et notez la limite finale et sa justification.

Prévention et vérification du correctif

• Documentez les tailles maximales prises en charge pour les requêtes, les fichiers et les requêtes multipart de chaque route d’envoi ou d’API.
• Gardez les limites de l’application, du serveur web, du proxy, du CDN et du WAF visibles et sous contrôle de version lorsque cela est possible.
• Testez les tailles limites et des requêtes volumineuses représentatives dans un environnement hors production avant la mise en ligne.
• Surveillez les réponses 413 par route, méthode, client et déploiement afin de distinguer une hausse inattendue d’une limite intentionnelle.
• Veillez à ce que les clients valident la taille des fichiers et des payloads avant l’envoi et proposent une alternative claire lorsqu’une requête est trop volumineuse.
• Conservez suffisamment de journaux assainis du proxy et de l’application pour déterminer quelle couche a rejeté une requête, sans enregistrer de secrets ni de données personnelles superflues.

Questions fréquentes