Votre navigateur affiche une page blanche avec le message « 400 bad request request header or cookie too large » ?
Frustrant, non… Vous n’êtes pas le seul à rencontrer cette erreur qui bloque l’accès à un site. La bonne nouvelle : l’alternative est souvent simple et rapide.
Tout au long de ce texte, je vous explique pourquoi cette erreur apparaît, ce qu’elle signifie vraiment, et comment la corriger étape par étape, sans être développeur.
🧠 L’essentiel à retenir :
L’erreur 400 bad request liée aux cookies bloque l’accès à un site, mais se corrige facilement.
👉 Cause principale : les cookies accumulés dans le navigateur dépassent la limite acceptée par le serveur (8 Ko par défaut sur Nginx).
👉 Premier réflexe : tester en navigation privée, puis supprimer les cookies du domaine concerné et vider le cache.
👉 Si l’erreur persiste : le problème vient du serveur — augmenter les limites via nginx.conf ou LimitRequestFieldSize sur Apache.
👉 Solution durable : définir une politique d’expiration des cookies avec l’attribut Max-Age pour éviter toute récidive.
Cette erreur HTTP 400 est un message envoyé par le serveur pour dire, en gros : « ta requête est trop lourde, je ne peux pas la traiter« . Plus précisément, c’est la taille des en-têtes HTTP ou des cookies attachés à votre requête qui dépasse la limite acceptée par le serveur.
Un cookie, c’est un petit fichier texte que votre navigateur stocke localement pour mémoriser des informations : session de connexion, préférences d’affichage, panier d’achat… Normalement, ils restent légers. Mais parfois, après de nombreuses visites sur un site, ou suite à des bugs d’applications web, ces cookies s’accumulent et gonflent. Le serveur Nginx (l’un des serveurs web les plus utilisés au monde, présent sur plus de 34 % des sites actifs selon W3Techs) fixe par défaut une limite de 8 Ko pour les en-têtes. Dépassez cette limite, et voilà l’erreur.
L’erreur 400 liée aux cookies ou aux en-têtes HTTP trop volumineux survient quand le navigateur envoie plus de données que le serveur n’est configuré pour en accepter.
Ce problème touche souvent des sites utilisant des CMS comme WordPress, Magento ou Drupal, où les plugins et modules peuvent multiplier les cookies sans contrôle. Un utilisateur connecté depuis longtemps sur une boutique en ligne peut, par exemple, accumuler des dizaines de cookies de session, déclenchant cette erreur sans prévenir.
Bonne nouvelle : dans la immense majorité des cas, vous pouvez résoudre ce problème vous-même, sans toucher au serveur. La cause principale reste l’accumulation de cookies dans votre navigateur. Voici donc par où commencer.
La première action à faire : vider les cookies pour le site concerné. Pas besoin de tout supprimer, seulement ceux liés au domaine problématique. Sur Chrome, ouvrez les paramètres, allez dans « Confidentialité et sécurité », puis « Cookies et autres données de sites », et recherchez le domaine en question pour le supprimer.
| Navigateur | Accès aux cookies | Raccourci clavier |
|---|---|---|
| Google Chrome | Paramètres > Confidentialité > Cookies | Ctrl + Shift + Suppr |
| Mozilla Firefox | Paramètres > Vie privée > Cookies | Ctrl + Shift + Suppr |
| Safari | Préférences > Confidentialité > Gérer | Cmd + Option + E |
| Microsoft Edge | Paramètres > Confidentialité > Effacer | Ctrl + Shift + Suppr |
Après avoir supprimé les cookies, rechargez la page. Si l’erreur disparaît, le problème venait bien de données accumulées côté client. Pensez aussi à vider le cache du navigateur en même temps, car certains fichiers mis en cache peuvent contenir des données corrompues qui aggravent la situation.
Une autre astuce utile : testez le site en navigation privée. Ce mode démarre sans cookies ni cache, ce qui confirme rapidement si l’erreur vient de votre navigateur ou du serveur. Si le site s’ouvre normalement en navigation privée mais pas en mode normal, vous avez votre réponse.
Tester un site en navigation privée prend moins de 30 secondes et permet d’identifier immédiatement si l’erreur 400 provient de votre navigateur ou du serveur distant.
Voici les étapes à suivre dans l’ordre logique :
- Tester le site en navigation privée pour isoler la cause
- Supprimer les cookies liés au domaine problématique
- Vider le cache du navigateur
- Redémarrer le navigateur et retenter l’accès
- Essayer depuis un autre navigateur ou appareil
Et si l’erreur persiste côté serveur ?
Vous avez tout tenté côté navigateur, mais l’erreur revient. Là, le problème vient probablement du serveur. Si vous êtes propriétaire du site ou développeur, quelques ajustements techniques peuvent régler la situation définitivement.
Sur un serveur Nginx, la directive largeclientheader_buffers contrôle la taille maximale des en-têtes acceptés. Par défaut, elle est fixée à 4 buffers de 8 Ko. En l’augmentant à 16 Ko ou 32 Ko, vous donnez plus de marge au serveur pour traiter les requêtes volumineuses. Cette modification se fait dans le fichier de configuration nginx.conf, généralement situé dans /etc/nginx/.
Sur Apache, c’est la directive LimitRequestFieldSize qui entre en jeu. Sa valeur par défaut est de 8 190 octets. L’augmenter à 16 000 ou 32 000 octets règle la plupart des cas. Attention pourtant : développer ces limites sans raison valable expose le serveur à des risques de sécurité, spécialement les attaques par injection d’en-têtes.
Une approche plus propre consiste à identifier quels cookies ou en-têtes dépassent les limites et à nettoyer la logique applicative qui les génère. Un audit des cookies actifs sur votre site, via l’outil « Inspecter » du navigateur (onglet « Application » sur Chrome), permet de repérer les cookies inutiles ou surdimensionnés.
Modifier les limites côté serveur sans nettoyer les cookies applicatifs revient à agrandir la boîte aux lettres sans trier le courrier : le problème revient tôt ou tard.
Si votre site tourne sur un hébergement mutualisé, contactez directement votre hébergeur en lui signalant l’erreur 400. Beaucoup de panneaux d’administration comme cPanel permettent d’ajuster ces paramètres sans accès SSH. OVHcloud, par exemple, propose une assistance technique réactive pour ce type de configuration sur ses offres managées.
Bref, corriger une erreur de requête HTTP invalide liée aux en-têtes nécessite d’agir des deux côtés : navigateur d’abord, serveur ensuite si nécessaire. Mais voici ce qu’on oublie régulièrement : mettre en place une politique d’expiration des cookies côté application (en définissant un attribut Max-Age raisonnable) évite que le problème ne revienne. C’est une bonne pratique simple qui épargne bien des maux de tête à long terme.
