Erreur 413 Request Entity Too Large : augmenter la taille d'envoi

TL;DRL'erreur 413 apparaît quand vous envoyez un fichier ou un formulaire plus gros que ce qu'accepte le serveur. Pour la corriger, il faut relever la limite de chaque étage traversé : Cloudflare, nginx ou Apache, puis PHP. La plus petite de ces limites décide, quelle que soit la valeur des autres.

⚠️ Que signifie l'erreur 413 ?#

L'erreur 413 signifie que le serveur refuse votre requête parce que son contenu est trop volumineux. Le cas typique : vous envoyez un fichier (une image, une vidéo, un fichier CSV, l'archive ZIP d'un thème) et l'une des couches entre votre navigateur et le site a une limite plus basse que la taille de ce fichier.

Le libellé a changé avec le temps. Les anciens textes parlaient de Request Entity Too Large, puis de Payload Too Large. La RFC 9110, qui définit aujourd'hui la sémantique HTTP, l'appelle 413 Content Too Large. Le sens n'a pas bougé : le corps de la requête dépasse ce que le serveur accepte de traiter. Si le refus n'est que temporaire, la RFC recommande d'ajouter un en-tête Retry-After.

Cette erreur fait partie de la famille des codes 4xx, ceux qui concernent la requête du client. Vous retrouverez les autres codes de cette famille sur notre page codes d'erreur HTTP.

📌 Pourquoi la limite la plus basse gagne#

Un envoi de fichier traverse plusieurs étages, et chacun a son propre plafond. Il suffit qu'un seul soit trop bas pour bloquer l'envoi. C'est pour cela qu'augmenter une seule valeur ne suffit souvent pas.

Un point souvent mal compris : PHP ne renvoie pas lui-même de 413. Quand un fichier dépasse upload_max_filesize ou que la requête dépasse post_max_size, PHP vide les données reçues et laisse l'application gérer. WordPress affiche alors par exemple « Le fichier téléversé dépasse la directive upload_max_filesize dans php.ini ». Une vraie page 413 vient donc presque toujours du serveur web ou du CDN.

📌 Côté visiteur : ce que vous pouvez faire#

Si vous n'êtes pas le propriétaire du site, vous ne pouvez pas changer ses limites. Vous pouvez en revanche réduire ce que vous envoyez :

• Compressez le fichier : une photo de smartphone peut être réduite en dimensions ou convertie en JPEG ou WebP avant l'envoi.
• Découpez l'envoi : envoyez plusieurs fichiers en plusieurs fois plutôt qu'un seul formulaire chargé de pièces jointes.
• Passez par un lien : pour un gros document, partagez un lien de téléchargement plutôt que le fichier lui-même, si le formulaire l'accepte.
• Prévenez le site : indiquez la taille du fichier et l'heure de l'erreur. Le propriétaire saura quelle limite relever.

Si le message apparaît sur une page normale, sans envoi de fichier, la cause est différente : un cookie trop gros ou une requête mal formée renvoient plutôt une erreur 400.

📌 Côté propriétaire : identifier l'étage qui bloque#

Avant de modifier quoi que ce soit, regardez qui a produit la page d'erreur. Une page 413 aux couleurs de Cloudflare vient de Cloudflare. Une page blanche minimaliste avec « nginx » en bas vient de nginx. Le journal d'erreurs confirme : nginx y écrit le message client intended to send too large body avec la taille reçue.

sudo grep "too large body" /var/log/nginx/error.log | tail -n 5

Ensuite, vérifiez les valeurs PHP réellement appliquées. Attention : php -i affiche la configuration de PHP en ligne de commande, qui utilise souvent un autre php.ini que PHP-FPM ou le module Apache.

php -i | grep -E "upload_max_filesize|post_max_size|memory_limit"
php --ini

Pour connaître les valeurs vues par le site lui-même, créez un fichier temporaire à la racine, ouvrez-le dans le navigateur, puis supprimez-le aussitôt (il expose des informations sur votre serveur) :

<?php phpinfo();

Dans la page affichée, la colonne Local Value donne la valeur appliquée au dossier, et la ligne Loaded Configuration File indique le fichier php.ini à modifier.

📌 Augmenter la limite dans nginx#

La directive client_max_body_size s'utilise dans les blocs http, server ou location. Mieux vaut la placer dans le bloc server du site concerné plutôt que de l'ouvrir pour tout le serveur.

server {
    server_name exemple.fr;
    client_max_body_size 64M;
    # ...
}

Testez la syntaxe avant de recharger. Si le test échoue, ne rechargez pas : corrigez d'abord.

sudo nginx -t && sudo systemctl reload nginx

La valeur 0 désactive le contrôle. Évitez-la : une limite raisonnable protège le serveur contre les envois abusifs. Si nginx sert de proxy devant Apache, réglez les deux.

📌 Augmenter la limite dans Apache#

LimitRequestBody s'exprime en octets et s'utilise dans la configuration du serveur, du virtual host, d'un dossier ou d'un fichier .htaccess. Pour 64 Mio :

LimitRequestBody 67108864

Sur les versions récentes d'Apache, la valeur par défaut est déjà de 1 Gio : si vous avez une 413 sous Apache, cherchez une valeur plus basse posée par un hébergeur ou un panneau d'administration.

sudo grep -Rn "LimitRequestBody" /etc/apache2/
sudo apache2ctl configtest && sudo systemctl reload apache2

📌 Augmenter la limite dans PHP#

Trois réglages fonctionnent ensemble. La documentation PHP est claire : post_max_size doit être plus grand que upload_max_filesize, et de façon générale memory_limit doit être plus grand que post_max_size.

upload_max_filesize = 64M
post_max_size = 72M
memory_limit = 256M

Où écrire ces lignes dépend de la façon dont PHP tourne :

• PHP-FPM : dans le php.ini du pool (par exemple /etc/php/8.3/fpm/php.ini), puis rechargez le service avec sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm. Adaptez le numéro de version au vôtre.
• Hébergement mutualisé sous PHP-FPM ou CGI : un fichier .user.ini à la racine du site accepte les mêmes lignes. Il est relu périodiquement, par défaut toutes les 300 secondes.
• Module Apache (mod_php) : la syntaxe php_value upload_max_filesize 64M dans le .htaccess fonctionne. Sous PHP-FPM, cette même ligne provoque une erreur 500.

upload_max_filesize et post_max_size ne peuvent pas être modifiés par ini_set() dans le code : ils sont lus avant l'exécution du script. Un plugin qui promet de « débloquer la limite » sans toucher à la configuration du serveur ne peut donc rien faire pour ces deux valeurs.

🌐 Cas WordPress : import de thème, d'extension ou de média#

WordPress affiche la limite effective dans Médias > Ajouter, sous la zone de dépôt (« Taille de fichier maximale pour le téléversement »). Si elle reste basse après vos changements, c'est que le php.ini modifié n'est pas celui utilisé par le site : revenez au contrôle par phpinfo().

Deux contournements évitent de relever les limites pour un envoi ponctuel :

• déposer le thème ou l'extension par SFTP dans wp-content/themes ou wp-content/plugins, puis l'activer depuis l'administration ;
• passer par WP-CLI, qui n'est pas soumis aux limites du serveur web :

wp theme install /chemin/vers/mon-theme.zip --activate
wp media import /chemin/vers/video.mp4

Sur un réseau multisite, une limite supplémentaire existe dans les réglages du réseau (taille maximale des fichiers envoyés). Elle s'ajoute à celles de PHP.

🛒 Cas PrestaShop : import de produits et d'images#

L'import CSV de PrestaShop (Paramètres avancés > Importer) envoie le fichier par un formulaire classique : il est donc soumis aux mêmes limites PHP et serveur web. Un catalogue complet avec des milliers de lignes dépasse vite quelques mégaoctets.

• Découpez le CSV en plusieurs fichiers de quelques milliers de lignes : l'import sera aussi moins exposé aux délais d'exécution.
• Envoyez les images à part : dans le CSV, la colonne d'images accepte des URL. PrestaShop les télécharge lui-même, ce qui évite d'envoyer un gros fichier par le navigateur.
• Automatisez les imports volumineux par le webservice plutôt que par le formulaire : voir notre guide sur l'API de PrestaShop.

Pour l'installation d'un module ou d'un thème en ZIP, le dépôt par SFTP dans modules/ ou themes/ reste la solution la plus simple quand l'archive est lourde.

📌 Cas Cloudflare : la limite d'envoi dépend de l'offre#

Quand un domaine passe par le proxy Cloudflare, chaque requête entrante est soumise à une taille maximale. La documentation de Cloudflare indique 100 Mo pour les offres Free et Pro, 200 Mo pour Business, et jusqu'à 5 Go pour Enterprise. Au-delà, Cloudflare répond lui-même par une 413, sans que la requête atteigne votre serveur. La limite peut être abaissée dans les réglages réseau de la zone, ce qui provoque aussi des 413 si elle est fixée trop bas.

Les solutions proposées par Cloudflare :

• découper l'envoi en requêtes plus petites (envoi par morceaux), si votre application le permet ;
• servir l'envoi par un sous-domaine en mode « DNS only », non proxifié ;
• changer d'offre si les gros envois sont au cœur de votre activité.

Pour vérifier qu'un sous-domaine est bien en DNS seul, son enregistrement doit pointer directement vers l'IP de votre serveur. Un outil de vérification DNS vous l'affiche en quelques secondes.

📌 Vérifier que la correction fonctionne#

Créez un fichier de test légèrement plus petit que la nouvelle limite, puis envoyez-le avec curl. Le code affiché doit ne plus être 413.

head -c 50M /dev/urandom > test-50M.bin
curl -s -o /dev/null -w "%{http_code}\n" -F "fichier=@test-50M.bin" https://exemple.fr/chemin-du-formulaire

Remplacez l'URL par celle qui reçoit vraiment l'envoi. Le code obtenu peut être 403 ou 419 si le formulaire attend un jeton de sécurité : ce n'est plus un problème de taille. Supprimez ensuite le fichier de test.

💡 Notre conseil#

Fixez des limites cohérentes d'un étage à l'autre : la valeur du serveur web légèrement au-dessus de post_max_size, elle-même au-dessus de upload_max_filesize. Restez proche de vos besoins réels plutôt que de tout ouvrir. Websource héberge un grand nombre de sites WordPress et PrestaShop et règle ces valeurs avec vous dès la commande, selon vos usages (imports de catalogue, vidéos, médias). Consultez nos offres d'hébergement WordPress et d'hébergement PrestaShop : la migration est offerte en offres Premium et Advanced, et sur devis en Standard.

❓ Questions fréquentes#

📌 Quelle différence entre 413 Request Entity Too Large et 413 Payload Too Large ?#

Aucune sur le fond : c'est le même code HTTP sous des noms successifs. La RFC 9110 l'appelle aujourd'hui Content Too Large. Tous signifient que le contenu envoyé dépasse la limite du serveur.

📌 J'ai modifié php.ini mais la limite ne change pas, pourquoi ?#

Vous avez probablement modifié le php.ini de la ligne de commande et non celui de PHP-FPM ou du module Apache. Affichez phpinfo() depuis le navigateur et regardez la ligne Loaded Configuration File. Pensez aussi à recharger le service PHP-FPM.

📌 Peut-on supprimer complètement la limite ?#

Techniquement oui, avec client_max_body_size 0 dans nginx ou LimitRequestBody 0 dans Apache. Ce n'est pas conseillé : une limite raisonnable protège le serveur contre les envois abusifs. Choisissez une valeur adaptée à vos plus gros fichiers réels.

🌐 L'erreur 413 vient-elle de Cloudflare ou de mon serveur ?#

Regardez la page d'erreur : Cloudflare affiche sa propre page à son nom. Si la requête n'apparaît pas dans les journaux de votre serveur, elle a été bloquée avant. Au-delà de 100 Mo en offre Free ou Pro, c'est Cloudflare qui refuse.

🌐 Comment importer un gros thème WordPress sans toucher au serveur ?#

Déposez le dossier du thème par SFTP dans wp-content/themes, puis activez-le dans l'administration. Vous pouvez aussi utiliser WP-CLI avec wp theme install suivi du chemin du fichier ZIP.

Article publié le 13/11/2026 sous la signature de Jonathan Gutierrez, rédigé à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.