Un soir, en ouvrant un service de streaming sportif auquel je suis abonné, je suis tombé sur une page blanche et une seule ligne de texte : request headers too large. Pas de logo, pas de bouton, pas d'explication. Le même compte fonctionnait pourtant sans problème sur un autre navigateur installé sur la même machine. C'est ce détail qui m'a mis sur la piste : le problème ne venait ni de mon abonnement, ni du service, mais de ce que mon navigateur envoyait à chaque requête.
Cette erreur revient régulièrement dans les demandes que je reçois, aussi bien de particuliers bloqués sur un site que de dirigeants dont les visiteurs signalent une page inaccessible. Le mécanisme est toujours le même et se corrige en quelques minutes côté visiteur. Côté éditeur de site, en revanche, elle mérite un vrai diagnostic : une erreur d'en-têtes trop volumineux qui frappe une partie de vos visiteurs est une panne commerciale silencieuse. Voici ce que le message signifie, pourquoi les cookies en sont presque toujours la cause, et comment traiter les deux côtés du problème.
Ce que signifie « request headers too large »
Chaque fois que votre navigateur demande une page, il envoie d'abord une série d'en-têtes HTTP : l'adresse demandée, la langue, le type de navigateur, la page d'où vous venez (Referer) et surtout les cookies associés au domaine (Cookie). Ces en-têtes précèdent la réponse du serveur et doivent tenir dans une zone mémoire dont la taille est fixée à l'avance. Quand ils dépassent cette limite, le serveur ne peut pas lire la requête et la rejette sans même la traiter.
Le code HTTP prévu pour ce cas est le 431 Request Header Fields Too Large, défini par la RFC 6585 publiée en avril 2012 par Mark Nottingham et Roy Fielding. La spécification précise que le serveur peut refuser la requête soit parce que l'ensemble des en-têtes est trop volumineux, soit parce qu'un seul champ l'est, et que la réponse doit alors indiquer lequel. Elle ajoute une contrainte utile à connaître : une réponse 431 ne doit jamais être mise en cache. La documentation MDN sur le code 431, mise à jour le 11 juillet 2026, cite deux causes classiques : une URL trop longue dans l'en-tête Referer, et une requête qui contient trop de cookies.
431, 400, 404 : pourquoi le code affiché varie
Dans la vraie vie, le code que vous voyez dépend du serveur qui a bloqué la requête, et ce n'est pas toujours un 431. C'est une source de confusion classique : un visiteur signale une « erreur 400 », le développeur cherche une requête mal formée, alors que la cause réelle est un en-tête Cookie de plusieurs kilo-octets.
| Serveur | Limite par défaut | Réponse renvoyée |
|---|---|---|
| nginx | 1 Ko pour le premier tampon, puis 4 tampons de 8 Ko | 400 Bad Request si un champ dépasse la taille d'un tampon |
| Apache HTTP Server | 8 190 octets par champ d'en-tête, 100 champs au maximum | Erreur 400 côté client |
| IIS | Limites d'en-têtes définies dans headerLimits |
404 avec le sous-statut 431 « Request Header Too Long » |
Ces valeurs viennent des documentations officielles : la directive large_client_header_buffers de nginx vaut par défaut 4 8k, précédée d'un client_header_buffer_size de 1 Ko ; la directive LimitRequestFieldSize d'Apache 2.4 est fixée à 8 190 octets, avec un LimitRequestFields à 100 ; et la documentation IIS sur requestLimits indique qu'un dépassement des limites d'en-têtes renvoie un 404 assorti du sous-statut 431.
Ajoutez à cela les couches intermédiaires. Un CDN ou un reverse proxy applique ses propres seuils, souvent plus bas que celui de votre serveur d'origine : Cloudflare, par exemple, documente une limite totale de 128 Ko pour les en-têtes de requête. C'est souvent le maillon le plus strict de la chaîne qui décide, et pas celui que vous administrez.
Pourquoi les cookies sont presque toujours en cause
Parmi tous les en-têtes envoyés, un seul grossit sans limite visible avec le temps : Cookie. Le navigateur y empile la totalité des cookies valides pour le domaine demandé, à chaque requête, y compris pour une simple image. Session, panier, préférences de langue, consentement, outils de mesure, test A/B, chat d'assistance : chaque brique ajoute la sienne, et personne ne fait le ménage.
Le brouillon draft-ietf-httpbis-rfc6265bis, qui doit remplacer la RFC 6265 et se trouve en revue finale chez l'éditeur RFC (version 22, août 2026), donne les ordres de grandeur retenus par les navigateurs : un cookie dont la somme du nom et de la valeur dépasse 4 096 octets est ignoré, un attribut de plus de 1 024 octets est écarté. Le texte suggère aussi, sans l'imposer, qu'un navigateur puisse purger les cookies excédentaires au-delà d'environ 50 cookies pour un même domaine, ou 3 000 au total. Retenez la logique : un seul cookie ne fait jamais tomber un serveur, mais quarante cookies de deux kilo-octets dépassent allègrement le tampon de 8 Ko d'Apache ou de nginx.
Deux scénarios déclenchent le blocage. Le premier est l'accumulation lente : un compte utilisé depuis des années sur le même navigateur, avec des cookies d'authentification renouvelés sans que les anciens expirent. Le second est la panne franche : une mise à jour applicative qui écrit un jeton volumineux, un système d'authentification unique qui stocke un ticket entier dans un cookie, ou un sous-domaine qui hérite des cookies posés sur le domaine parent. Dans mon cas, c'était le premier scénario, et il explique pourquoi le service fonctionnait sur un navigateur que j'utilisais rarement : celui-là n'avait tout simplement rien accumulé.
Côté visiteur : rétablir l'accès en quelques minutes
Si vous êtes le visiteur bloqué, la correction est simple et sans risque. Elle consiste à supprimer les cookies du domaine concerné, uniquement de ce domaine.
- Ouvrez la page qui affiche l'erreur, puis cliquez sur l'icône située à gauche de l'adresse dans la barre du navigateur.
- Ouvrez le panneau relatif aux cookies et aux données du site, puis supprimez les données enregistrées pour ce domaine. Les libellés varient selon le navigateur et sa version.
- Fermez l'onglet, rouvrez le site et reconnectez-vous.
Si l'erreur persiste, passez par les paramètres du navigateur, section confidentialité, et supprimez les cookies et données de sites. C'est ce que j'avais fini par faire ce soir-là, faute de trouver le bon sous-domaine : la suppression globale a réglé le problème en une fois. Sachez simplement ce que vous perdez : vous serez déconnecté de tous les sites et vos préférences de consentement seront réinitialisées. En revanche, les mots de passe enregistrés dans le navigateur ne sont pas concernés, ils relèvent d'un stockage distinct. Une navigation privée permet de confirmer le diagnostic en dix secondes : si le site s'ouvre normalement dans une fenêtre privée, où aucun cookie n'est encore posé, la cause est bien locale.
Côté éditeur : traiter la cause, pas le symptôme
Si c'est votre site qui renvoie l'erreur, le réflexe habituel consiste à augmenter les tampons du serveur. C'est une réponse légitime en urgence, mais insuffisante seule : vous repoussez le plafond au lieu de réduire la charge.
Réduire le volume de cookies envoyés
Commencez par l'inventaire. Ouvrez les outils de développement de votre navigateur, onglet réseau, et regardez la taille de l'en-tête Cookie envoyé sur une requête quelconque. Puis listez les cookies posés par votre domaine et identifiez leur origine. Sur un site WordPress chargé d'extensions, il est fréquent d'en trouver plusieurs dizaines, dont une partie provient de modules désactivés depuis longtemps. Trois leviers donnent des résultats immédiats : supprimer les cookies des outils que vous n'utilisez plus, stocker côté serveur les données volumineuses en ne gardant qu'un identifiant court dans le cookie, et cantonner les cookies techniques à un sous-domaine ou à un chemin précis plutôt que de les poser sur le domaine entier. Servir les fichiers statiques depuis un domaine distinct évite en prime d'envoyer tous ces cookies avec chaque image. Ce travail rejoint directement celui d'optimisation de la vitesse du site : moins d'octets par requête, c'est aussi moins de latence.
Ajuster les limites serveur, avec mesure
Une fois le ménage fait, ajustez les seuils. Sur nginx, large_client_header_buffers 4 16k; double la capacité par défaut. Sur Apache, LimitRequestFieldSize 16384 joue le même rôle. Sur IIS, la valeur se règle dans l'élément headerLimits. Deux précautions : la documentation Apache rappelle qu'augmenter le nombre de champs autorisés expose davantage aux attaques par déni de service, et il faut répercuter le réglage sur toute la chaîne, reverse proxy et CDN compris, sinon le maillon le plus strict continuera de bloquer. Vérifiez aussi le comportement de votre applicatif : beaucoup d'environnements applicatifs imposent leur propre plafond d'en-têtes, indépendant de celui du serveur web.
Surveiller pour ne pas découvrir la panne par un client
Une erreur 431 ou 400 n'apparaît pas dans les statistiques d'audience : le script de mesure ne se charge jamais, puisque la page n'est pas rendue. Le seul endroit où elle est visible, ce sont les journaux du serveur. Filtrez-y les codes 400 et 431 chaque mois. Côté référencement, l'impact est réel si le blocage touche les robots : une page qui répond systématiquement en erreur finit par sortir de l'index. Un audit SEO technique permet de croiser les journaux, les réponses HTTP et l'état d'indexation pour savoir si le problème est anecdotique ou structurel. Si l'erreur provient d'une accumulation d'extensions sur un site ancien, une refonte WordPress ou une reconstruction propre du site est parfois plus rationnelle qu'un empilement de correctifs.
Questions fréquentes
Que signifie l'erreur « request headers too large » ?
Elle indique que le serveur refuse de traiter la requête parce que les en-têtes HTTP envoyés par le navigateur dépassent la taille qu'il accepte. Le code prévu pour ce cas est le 431 Request Header Fields Too Large, mais beaucoup de serveurs répondent par une erreur 400 Bad Request. La cause la plus fréquente est un en-tête Cookie devenu trop volumineux.
Supprimer mes cookies va-t-il effacer mes mots de passe enregistrés ?
Non. Les mots de passe enregistrés par le navigateur sont stockés séparément des cookies et ne sont pas supprimés lorsque vous videz les cookies et données de sites. Vous serez en revanche déconnecté des sites où vous étiez identifié et vos préférences de consentement seront réinitialisées.
Pourquoi le site fonctionne-t-il sur un autre navigateur ?
Parce que les cookies ne sont pas partagés entre navigateurs : chacun tient son propre stockage. Un navigateur peu utilisé n'a accumulé que peu de cookies pour le domaine concerné et reste donc sous la limite du serveur. Ce test est d'ailleurs un bon moyen de confirmer que la cause est locale et non un incident côté site.
Faut-il supprimer tous les cookies ou seulement ceux d'un site ?
Commencez toujours par les cookies du seul domaine concerné, c'est suffisant dans la majorité des cas et bien moins gênant. La suppression globale devient utile quand les cookies fautifs sont posés sur plusieurs sous-domaines et que vous ne parvenez pas à identifier le bon. Une fenêtre de navigation privée permet de vérifier le diagnostic avant de supprimer quoi que ce soit.
Quelle est la taille maximale d'un cookie ?
Les navigateurs ignorent un cookie dont le nom et la valeur additionnés dépassent 4 096 octets, seuil retenu par la spécification en cours de finalisation qui doit remplacer la RFC 6265. Un attribut de plus de 1 024 octets est également écarté. Le problème vient rarement d'un cookie isolé, mais du cumul de dizaines de cookies envoyés ensemble à chaque requête.
Cette erreur peut-elle nuire au référencement du site ?
Oui, si elle touche les robots d'exploration et pas seulement quelques visiteurs. Une page qui répond durablement en erreur 400 ou 431 n'est pas explorable et finit par être désindexée. Comme ces requêtes n'apparaissent pas dans les outils de mesure d'audience, seul l'examen des journaux du serveur permet de repérer le phénomène.