Une erreur 400 qui apparaît et disparaît, dans l’administration d’un site Divi
La panne qui ne laisse aucune trace dans les journaux
Le scénario est toujours à peu près le même. Vous travaillez sur un site depuis une heure, vous ouvrez des pages les unes après les autres dans l’éditeur visuel, vous enregistrez, vous revenez à la liste des contenus. Et à un moment, sans que rien n’ait changé, le serveur répond 400 Bad Request.
Vous rechargez. Ça repasse. Vous continuez. Dix minutes plus tard, ça recommence — sur un autre écran, sur une action qui marchait tout à l’heure. Vous ouvrez les journaux d’erreur PHP : rien. Vous désactivez vos extensions une par une : le problème est toujours là, ou il a disparu pour de mauvaises raisons. Vous changez de navigateur : tout va bien, jusqu’à ce que ça revienne aussi.
Ce qui rend cette panne particulièrement coûteuse, ce n’est pas sa gravité — on récupère toujours son travail. C’est qu’elle ne ressemble à rien. Une erreur 500 pointe vers PHP, une page blanche vers une fatale, un 403 vers des droits. Un 400 dit seulement que le serveur a refusé la requête avant même de la transmettre à WordPress : aucune ligne de code du site n’a été exécutée, et donc rien n’a pu être journalisé.
Le geste qui marche, et pourquoi il ne règle rien
À force de chercher, on finit toujours par trouver le même remède : vider les cookies du site. Et ça marche — immédiatement, complètement. Pendant deux jours, plus rien. Puis la panne revient, et on revide.
Ce cycle est le vrai coût. Chaque retour du problème relance une demi-heure de doute : est-ce l’hébergeur ? une mise à jour ? le site est-il en train de casser ? On finit par le mentionner au client comme « un truc du serveur », faute de mieux, et par le vivre comme un bruit de fond du projet. Sur un site qu’on livre à quelqu’un, c’est exactement le genre de chose dont on préférerait ne pas avoir à parler.
La panne tombe rarement en début de session : elle arrive après une heure ou deux de travail, quand la fatigue rend le diagnostic plus difficile — Photo par Julien Bachelet via Pexels
Pourquoi vider ses cookies fait disparaître une erreur 400 sur un site WordPress
Un jeu de cookies par contenu ouvert dans l’éditeur
Le constructeur de pages Divi a besoin de savoir quel contenu est en cours d’édition, lequel est en train d’être enregistré, et lequel vient de l’être. Il le mémorise dans des cookies, et il en pose un jeu par contenu ouvert — leurs noms se terminent par l’identifiant de la page concernée.
Ces cookies sont transitoires par nature : une fois la page fermée, ils ne servent plus à rien. Mais rien ne les retire. Ils restent dans le navigateur, et chaque nouvelle page ouverte dans l’éditeur en ajoute d’autres. Sur une journée de production — vingt, trente contenus repris —, le navigateur en accumule plusieurs dizaines.
Or le navigateur renvoie tous ses cookies à chaque requête, dans un seul en-tête HTTP. Cet en-tête grossit donc à mesure que la journée avance. Et les serveurs web plafonnent la taille d’un en-tête : sous Apache, le réglage s’appelle LimitRequestFieldSize et vaut classiquement quelques kilo-octets. Passé ce seuil, le serveur refuse la requête sans la lire — c’est le 400 Bad Request.
Tout s’explique alors. L’intermittence : le seuil se franchit progressivement, et la panne apparaît quand on a suffisamment travaillé. Le silence des journaux : WordPress n’a jamais reçu la requête. L’efficacité du vidage de cookies : il ramène l’en-tête à sa taille de départ. Et le retour du problème : la cause, elle, n’a pas bougé.
Retirer les cookies périmés plutôt que de les vider tous
Le vidage manuel a un défaut, en plus d’être à refaire : il emporte aussi le cookie du contenu sur lequel on travaille, et donc l’enregistrement automatique en cours. Ce qu’on veut, ce n’est pas tout supprimer — c’est supprimer ce qui ne sert plus.
C’est ce que fait l’Extension WordPress « Toolkit oaka » : à chaque chargement d’un écran de l’administration, elle repère les cookies d’éditeur qui portent l’identifiant d’un contenu autre que celui en cours d’édition, et les fait expirer. Le cookie du contenu ouvert est conservé, l’enregistrement automatique n’est pas perturbé, et l’en-tête de requête cesse de grossir. Le nettoyage n’a lieu que sur un site dont le thème actif est Divi, uniquement pour un utilisateur connecté, et uniquement dans l’administration : le site public n’est pas concerné.
Le réglage est actif par défaut, y compris sur un site où l’extension était déjà installée, et il se désactive d’une case si l’on veut vérifier que c’est bien lui qui a supprimé la panne. Il fait partie du même lot que les autres réglages qu’on repasse à chaque livraison — ceux dont nous parlions dans l’article sur les réglages WordPress à refaire à chaque nouveau site.
Une remarque, pour finir, sur ce que ce remède ne fait pas : il traite la cause la plus fréquente d’un 400 intermittent dans une administration WordPress, pas toutes. Un en-tête gonflé par un autre mécanisme, un pare-feu applicatif, une URL anormalement longue produiront le même code d’erreur. Si la panne persiste alors que les cookies d’éditeur sont nettoyés, c’est ailleurs qu’il faut chercher — mais au moins, on aura écarté le suspect numéro un.
Ce nettoyage est inclus dans la formule Boîte à outils de l’Extension WordPress « Toolkit oaka », aux côtés des autres réglages d’administration : c’est là que se trouve le nettoyage des cookies d’éditeur devenus inutiles, activable et désactivable depuis l’onglet Divers.
Photo à la une : Photo par energepic.com via Pexels