413 Content Too Large

Utilisation

Lorsque le message d’erreur 413 Content Too Large est reçu, le client envoie un corps de requête trop volumineux pour le serveur. Un exemple courant est celui d’un client qui tente d’envoyer un fichier d’un type et d’un format acceptables, mais dont la taille dépasse la limite autorisée. Les images, par exemple, sont souvent dans une résolution inutilement élevée et pèsent nettement moins une fois réduites, sans nuire à l’usage prévu. Plutôt que d’assumer la responsabilité de modifier les fichiers image, le serveur refuse le transfert et compte sur le client pour effectuer le traitement nécessaire.

Dans ces situations, le client vérifie la taille de fichier autorisée avant d’engager le PUT en utilisant l’en-tête Expect: 100-continue. Le serveur répond par un accusé de réception et, selon cette réponse, le corps du message est envoyé ou retenu.

Le serveur envoie éventuellement un en-tête Retry-After dans la réponse. S’il est présent, le client retente la requête après un délai indiqué ou à une date et une heure indiquées. Par exemple, si le client a dépassé son quota d’envoi pour la semaine, ou si les envois volumineux ne sont pas autorisés aux heures de pointe, le serveur suggérera de réessayer à un moment plus approprié.

Si la situation survient parce que le serveur n’a plus d’espace de stockage, le serveur envoie alors 507.

Le serveur inclut l’en-tête Connection: close pour mettre fin à la connexion, ce qui empêche le client d’envoyer le corps du message.

Remarque

Les WAF et les pare-feu de CDN (Cloudflare, AWS WAF) appliquent des limites de taille de corps indépendantes du serveur d’origine. Consultez les journaux du WAF ou du pare-feu si la limite du serveur d’origine est supérieure à la charge utile. Options pour réduire la taille de la charge utile : compresser avec Content-Encoding: gzip, mettre en place une pagination pour les grands ensembles de résultats, utiliser des envois multipart ou reprenables pour les fichiers volumineux.

Impact SEO

Les moteurs de recherche comme Google n’indexent pas une URL dont la réponse porte le statut 413. Les URL précédemment indexées seront retirées des résultats de recherche.

Exemple

Le client tente d’envoyer un fichier et le serveur répond 413 Content Too Large en raison d’un trafic important à ce moment-là. Le serveur refuse la requête, ferme la connexion et suggère au client de réessayer dans 30 minutes.

Requête

PUT /docs HTTP/1.1
Host: example.com
Content-Type: application/pdf
Content-Length: 10000

Réponse

HTTP/1.1 413 Content Too Large
Retry-After: 1800
Connection: close
Content-Type: text/html
Content-Length: 188

<html>
  <head>
    <title>File Too Large</title>
  </head>
  <body>
   <p>Too much server traffic to accept the transfer
   at this time. Try again after 30 minutes.</p>
  </body>
</html>

Comment corriger

L’erreur provient de la couche de la pile qui applique une limite de taille en premier : serveur web, reverse proxy, CDN ou framework applicatif. Identifiez la couche qui renvoie le 413 et ajustez-y la limite.

nginx : définissez client_max_body_size dans le bloc http, server ou location. La valeur 0 désactive entièrement la vérification (déconseillé en production). Redémarrez nginx après avoir modifié la valeur.

Apache : définissez LimitRequestBody dans httpd.conf ou .htaccess. La valeur est exprimée en octets, donc 10 Mo correspondent à 10485760. Rechargez Apache pour appliquer le changement.

IIS : modifiez l’attribut maxAllowedContentLength dans le fichier web.config, sous system.webServer > security > requestFiltering > requestLimits.

PHP : ajustez à la fois upload_max_filesize et post_max_size dans php.ini. La valeur de post_max_size doit être supérieure ou égale à celle d’upload_max_filesize.

Node.js / Express : définissez l’option limit dans body-parser ou dans le middleware JSON/URL-encoded intégré d’Express, par exemple express.json({ limit: ‘50mb’ }).

Cloudflare : les offres Free et Pro plafonnent les envois à 100 Mo, Business à 200 Mo et Enterprise à 500 Mo. Les envois dépassant ces limites renvoient 413 avant même d’atteindre le serveur d’origine. Pour les envois de fichiers volumineux derrière Cloudflare, contournez le proxy ou utilisez des stratégies d’envoi par fragments.

Côté client, compressez ou fragmentez les charges utiles volumineuses avant l’envoi. Pour les envois de fichiers, mettez en œuvre des protocoles d’envoi multipart ou reprenables afin de rester dans les limites du serveur. Utilisez le mécanisme Expect: 100-continue pour vérifier si le serveur acceptera la taille de la charge utile avant de transmettre le corps complet.

Références de code

.NET

HttpStatusCode.RequestEntityTooLarge

Rust

http::StatusCode::PAYLOAD_TOO_LARGE

Rails

:payload_too_large
:request_entity_too_large

http.StatusRequestEntityTooLarge

Symfony

Response::HTTP_REQUEST_ENTITY_TOO_LARGE

Python3.5+

http.HTTPStatus.REQUEST_ENTITY_TOO_LARGE

Java

java.net.HttpURLConnection.HTTP_ENTITY_TOO_LARGE

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_REQUEST_TOO_LONG

Angular

@angular/common/http/HttpStatusCode.PayloadTooLarge