413 Request Entity Too Large : causes et corrections

2026-09-19

Un 413 Payload Too Large, aussi appelé 413 Request Entity Too Large, signifie que le corps de la requête est plus grand qu'une limite fixée quelque part entre le client et l'application. Le serveur, ou quelque chose devant lui, a refusé de traiter le corps une fois qu'il a vu, ou estimé, sa taille.

Ce que signifie 413 Payload Too Large

La RFC 9110 définit le nom actuel comme 413 Content Too Large, bien que 413 Payload Too Large et l'ancien 413 Request Entity Too Large fassent tous deux référence au même code de statut et apparaissent encore à travers les serveurs, les frameworks, et les pages d'erreur. Quel que soit le libellé, la signification est identique : la requête elle-même était syntaxiquement correcte, mais son corps dépassait une limite de taille avant que le serveur n'accepte de la traiter. Cela arrive le plus souvent lors d'envois de fichiers, mais cela peut arriver sur n'importe quelle requête avec un gros corps, y compris une charge utile d'API en masse.

Comment l'erreur apparaît

Les navigateurs affichent généralement la page d'erreur simple que le serveur d'origine ou la bordure a renvoyée ; il n'existe pas d'interface dédiée du navigateur pour cela comme il en existe pour un échec de connexion. Il est courant de la voir échouer silencieusement dans un formulaire, avec la réponse visible seulement dans l'onglet réseau, particulièrement pour un envoi de fichier construit avec JavaScript. Depuis la ligne de commande, la réponse le confirme directement :

curl -i -X POST -F "[email protected]" https://example.com/upload
HTTP/1.1 413 Request Entity Too Large
Content-Type: text/html

Les journaux d'accès et d'erreur du serveur sont l'endroit le plus fiable pour confirmer la taille exacte en cause et quelle couche l'a rejetée, puisqu'une requête peut être bloquée au CDN, au serveur web, ou à l'application, et chacun la journalise différemment.

Ce qui provoque un 413

client_max_body_size de nginx. La valeur par défaut est 1 Mo, ce qui est assez petit pour que presque tout envoi de fichier réel la déclenche jusqu'à ce qu'elle soit explicitement relevée :
```
client_max_body_size 20M;
```
LimitRequestBody d'Apache. Réglé par répertoire ou globalement, et, comme nginx, a par défaut une taille que de nombreuses applications dépassent sans que personne ne la change délibérément.
upload_max_filesize et post_max_size de PHP. Deux réglages distincts dans php.ini qui doivent tous deux être assez grands pour l'envoi ; post_max_size doit être au moins aussi grand que upload_max_filesize, sinon le second réglage plafonne silencieusement le premier.
maxAllowedContentLength d'IIS. Réglé dans web.config sous requestLimits, par défaut à environ 30 Mo, et séparé du propre réglage maxRequestLength d'ASP.NET, qui utilise des unités différentes et doit être relevé en parallèle.
La limite d'envoi basée sur le forfait de Cloudflare. Les forfaits Free et Pro plafonnent la taille du corps de requête à 100 Mo indépendamment de ce que le serveur d'origine accepterait autrement, et cette limite ne peut pas être relevée depuis la propre configuration de l'origine ; il faut la traiter du côté de Cloudflare ou la contourner avec un chemin d'envoi direct qui évite le proxy.
Les limites de charge utile de la passerelle d'API. Les passerelles d'API gérées plafonnent couramment les corps de requête bien en dessous de ce qu'un serveur web traditionnel autoriserait, souvent à quelques mégaoctets seulement, ce qui piège les équipes migrant une fonctionnalité d'envoi existante derrière une nouvelle passerelle.

Comment savoir de qui vient la faute

Ce n'est presque jamais la faute d'un visiteur au sens de faire quelque chose de mal ; le fichier qu'il envoie est simplement plus grand qu'une limite qui existe quelque part dans la chaîne, et la correction appartient à quiconque possède cette couche. Si le même fichier s'envoie bien sur un environnement et échoue sur un autre, comparez chaque couche du chemin de la requête, puisque nginx, PHP, et un CDN peuvent chacun avoir une limite différente et la plus petite l'emporte. Lancer une vérification HTTP avec un corps de requête proche de votre limite prévue, envoyée depuis l'extérieur de votre réseau, confirme quel est réellement le plafond effectif de bout en bout plutôt que de se fier à un seul fichier de configuration.

Comment corriger une erreur 413

Si vous êtes visiteur

Compressez le fichier avant de l'envoyer, en particulier les images et vidéos, qui rétrécissent souvent radicalement sans perte de qualité visible à des tailles typiques.
Divisez un gros envoi en morceaux plus petits si le site supporte les envois fragmentés ou reprenables, plutôt que d'envoyer une seule très grosse requête.
Vérifiez la limite d'envoi déclarée du site si une est publiée, puisque certains 413 fonctionnent comme prévu et la correction est simplement un fichier plus petit.

Si vous gérez le site

Relevez la limite de chaque couche ensemble, pas seulement une. Une seule requête passe généralement par un CDN, un serveur web, et un environnement d'exécution applicatif, et la plus petite limite configurée n'importe où dans cette chaîne détermine le plafond réel.
Fixez explicitement nginx et Apache plutôt que de dépendre des valeurs par défaut :
```
# nginx
client_max_body_size 20M;

# Apache
LimitRequestBody 20971520
```
Faites correspondre les deux réglages de PHP. Relevez à la fois upload_max_filesize et post_max_size, et assurez-vous que le second est égal ou supérieur au premier.
Mettez à jour ensemble requestLimits d'IIS et maxRequestLength d'ASP.NET dans web.config, puisqu'ils mesurent la même chose dans des unités différentes et doivent tous deux être relevés.
Contournez la limite de forfait de Cloudflare pour de réels gros fichiers en envoyant directement vers le stockage avec une URL signée, en évitant entièrement le chemin de requête en proxy, plutôt que d'essayer de relever une limite que ce niveau de forfait n'expose pas.
Vérifiez la propre limite de charge utile de la passerelle d'API séparément du service backend si une se trouve devant votre application ; elle peut rejeter une requête avant même que vos propres réglages applicatifs, plus généreux, n'aient une chance de s'appliquer.

Comment prévenir qu'un 413 ne bloque de vrais utilisateurs

Une limite fixée trop bas est facile à manquer jusqu'à ce que quelqu'un avec un gros fichier la rencontre, et à ce moment-là cela ressemble à une fonctionnalité d'envoi cassée plutôt qu'à une incompatibilité de configuration. Une vérification HTTP programmée qui soumet une requête proche de votre limite de taille prévue, avec une assertion sur le code de statut attendu, confirme que toute la chaîne l'accepte encore après tout changement à la configuration du CDN, du serveur web, ou de l'application. Combinée à une surveillance depuis plusieurs emplacements, elle détecte aussi une limite au niveau du CDN qui ne s'applique qu'à certains nœuds de bordure.

Erreurs associées

Voir 400 Bad Request, que certains serveurs renvoient à la place de 413 pour la même condition de corps surdimensionné, l'aperçu des 4xx pour la famille plus large, et 406 Not Acceptable ailleurs dans ce lot.

Questions fréquentes

413 Payload Too Large est-il la même chose que 413 Request Entity Too Large ?

Oui. La RFC 9110 a renommé le texte de statut en 413 Content Too Large, mais les deux anciens noms font référence au code de statut et à la signification identiques, et les trois formulations apparaissent encore sur le terrain selon la version du logiciel serveur.

Pourquoi mon envoi échoue-t-il même après avoir relevé le client_max_body_size de nginx ?

Une autre couche de la chaîne, couramment le post_max_size de PHP, une limite de forfait fixe d'un CDN, ou une passerelle d'API, impose probablement une limite plus petite indépendamment. Chaque couche entre le client et l'application doit autoriser la taille, pas seulement celle que vous avez changée.

Puis-je relever la limite de 100 Mo de Cloudflare sur le forfait gratuit ou pro ?

Pas depuis la propre configuration du serveur d'origine ; ce plafond est fixé par le niveau de forfait. Le contournement habituel est d'envoyer les gros fichiers directement vers le stockage en utilisant une URL signée qui évite le chemin de requête en proxy.

Le 413 compte-t-il comme un blocage de sécurité ?

Généralement pas. C'est habituellement une limite de ressource simple plutôt qu'une règle défensive, bien que certains WAF utilisent des corps anormalement gros comme un signal parmi d'autres pour décider de bloquer une requête.

Quelle est une limite d'envoi par défaut raisonnable si je n'en ai pas fixé une ?

Il n'existe pas de nombre universel ; cela dépend entièrement de ce que votre application a légitimement besoin d'accepter. Fixez-la délibérément en fonction de votre plus gros fichier légitime attendu plutôt que de laisser en place la valeur par défaut de chaque couche.