ERR_CONTENT_DECODING_FAILED sur WordPress : corriger la compression de la réponse

Reconnaître un échec de décodage malgré une réponse 200

Le navigateur affiche ERR_CONTENT_DECODING_FAILED, une page blanche ou une ressource qui ne se charge pas, alors que la requête peut porter le statut 200 OK. Le serveur a répondu, mais le navigateur n’arrive pas à décoder le contenu annoncé. Ce résultat ne signifie donc pas automatiquement que WordPress a cessé de fonctionner ou que la base de données est inaccessible.

La compression réduit les octets transférés, puis le navigateur reconstitue le contenu. Si l’annonce de compression et les octets reçus ne correspondent pas, ou si le flux compressé est interrompu, cette reconstitution peut échouer. Une double transformation mal gérée est une possibilité, mais elle ne doit pas être déduite du seul message.

L’objectif est de recevoir une réponse complète dont le décodage fonctionne, avec et sans la couche suspectée. Il faut identifier la requête exacte, comparer ses variantes puis modifier un seul réglage à la fois. Changer l’encodage des caractères en UTF-8 ou réenregistrer tous les articles n’est pas une réponse à cette erreur de compression.

Les lectures dans le navigateur sont possibles sans accès serveur. Sur WordPress.com ou un hébergement géré, transmettez ces observations au support si les réglages concernés ne vous sont pas ouverts. Les exemples de configuration qui suivent visent un responsable autorisé d’installation auto-hébergée. En multisite ou sur un serveur partagé, faites préciser quels autres sites héritent du réglage avant toute modification.

Identifier la requête dans le panneau Réseau

Commencez sans installer d’extension. Dans un navigateur Chromium, ouvrez les outils de développement avec F12 ou le menu d’inspection, puis choisissez Réseau, ou Network. Rechargez la page concernée avec le panneau ouvert. Le document principal peut réussir alors qu’un fichier JavaScript, une feuille de style ou une réponse appelée par l’éditeur échoue.

Travaillez d’abord sur une page publique sans identifiants. Les en-têtes et les exports réseau d’une session connectée peuvent contenir des informations privées. Une capture du message, du chemin de la ressource et des champs utiles suffit souvent ; n’envoyez pas un export complet sans en contrôler le contenu.

Si vous cochez Disable cache dans le panneau Réseau, notez-le : ce réglage agit sur le cache du navigateur tant que les outils sont ouverts. Il ne purge ni le cache WordPress, ni celui du serveur ou du CDN. Une fenêtre privée ne garantit pas non plus une nouvelle réponse produite à l’origine. Consultez les en-têtes sans utiliser le crayon qui permet de les remplacer localement : cela modifierait l’observation.

1. Ouvrez l’adresse qui échoue et rechargez une fois pour enregistrer les requêtes.
2. Sélectionnez la ligne signalée en erreur et relevez son adresse, son type et son statut.
3. Dans Headers, comparez les en-têtes de requête et de réponse ; notez notamment Accept-Encoding et Content-Encoding.
4. Recommencez dans une fenêtre privée sur cette même adresse publique. Si la panne dépend d’une langue ou d’un chemin précis, conservez cette variante comme cible du diagnostic.

Lire les en-têtes sans tirer une conclusion trop vite

Accept-Encoding indique les compressions que le client accepte ; Content-Encoding décrit celles appliquées à la réponse. Un serveur peut envoyer une réponse non compressée même si le client accepte gzip. À l’inverse, annoncer gzip ne suffit pas : le corps doit réellement correspondre à cette annonce et être complet.

Plusieurs compressions peuvent être appliquées si elles sont correctement déclarées dans l’ordre. Deux composants capables de compresser ne constituent donc pas, à eux seuls, la preuve d’une panne. Cherchez un comportement reproductible : une variante échoue, l’autre fonctionne, et une modification ciblée change le résultat.

Relevez également les indications de cache et, s’il existe, le champ Vary. Une couche qui distribue des variantes selon Accept-Encoding doit les gérer de façon cohérente. La présence du champ ne prouve pas que tous les intermédiaires le respectent. Ne supprimez pas manuellement Content-Encoding ou Content-Length pour faire disparaître le message : vous pourriez seulement masquer l’annonce d’un corps toujours incorrect et créer un autre résultat selon le visiteur.

Comparer deux réponses avec curl si vous avez un terminal

Ce contrôle facultatif vise une petite page publique de votre site, sans connexion ni action métier. Depuis un dossier local privé, lancez séparément les deux commandes ci-dessous en remplaçant l’URL. Sous PowerShell Windows, utilisez curl.exe à la place de curl pour appeler le programme prévu. Choisissez un dossier vide : les noms de sortie ci-dessous peuvent remplacer des fichiers existants. Les fichiers produits restent locaux et peuvent contenir des en-têtes à expurger avant transmission.

La première demande une réponse sans compression ; vérifiez l’absence de codage compressé dans ses en-têtes avant de la considérer comme telle. La seconde demande une compression prise en charge par votre binaire curl et tente son décodage. Ses capacités, visibles avec curl --version, peuvent différer de celles de Chrome, notamment pour Brotli ou Zstandard.

Les commandes effectuent de vrais téléchargements, bornés ici à cinq secondes pour la connexion et vingt secondes au total. --disable, placé en premier, ignore le fichier de configuration personnel de curl afin de ne pas hériter d’options inattendues. Elles ne suivent pas automatiquement les redirections. Si la réponse redirige, identifiez d’abord son adresse finale autorisée puis recommencez sur celle-ci.

Lisez le code HTTP affiché et les erreurs du terminal : un transfert terminé ne garantit pas une réponse 200, et une page 403 ne constitue pas la même réponse à comparer. Si seule la seconde échoue au décodage avec une réponse comparable, vous disposez d’un indice sur la variante compressée. Si les deux échouent, examinez aussi la connexion et le serveur. Un succès curl n’exclut pas une panne du navigateur, dont la négociation peut différer. Enfin, avec --compressed, le corps sauvegardé est décodé mais les en-têtes conservés peuvent toujours annoncer la compression d’origine : ne les réutilisez pas comme une réponse prête à servir.

curl --disable --connect-timeout 5 --max-time 20 --write-out 'HTTP %{http_code}\n' --header 'Accept-Encoding: identity' --dump-header identity.headers.txt --output identity.body 'https://votre-domaine.example/page-test/'
curl --disable --connect-timeout 5 --max-time 20 --write-out 'HTTP %{http_code}\n' --compressed --dump-header compressed.headers.txt --output compressed.body 'https://votre-domaine.example/page-test/'

Repérer les couches qui transforment la réponse

Dressez le trajet réel de la requête : navigateur, éventuel réseau de diffusion, proxy, serveur web, PHP et cache WordPress. Un fichier précompressé peut également être servi directement, sans repasser par PHP. Le réglage d’une extension n’agit pas nécessairement sur toutes ces couches.

Relevez ce qui a changé juste avant la panne : activation de compression, ajout de proxy, nouvelle règle serveur, génération de fichiers compressés ou mise à jour d’un cache. Cette chronologie sert à choisir un test ; elle ne démontre pas à elle seule la responsabilité du dernier composant modifié.

Comparez une adresse affectée et une adresse fonctionnelle de même type, dans les mêmes conditions de connexion et de langue. Si seules les pages publiques en cache échouent, examinez leur génération et leur distribution. Si les fichiers statiques échouent aussi, une transformation située après WordPress devient une piste à vérifier. Pour comparer l’origine et un intermédiaire, utilisez uniquement le moyen de diagnostic autorisé par l’hébergement : ne rendez pas une origine privée publique et ne changez pas les DNS du site pour une simple comparaison.

Préparer une modification isolée et son retour arrière

Conservez la configuration initiale et préparez une sauvegarde adaptée des fichiers et de la base avant de modifier les réglages du site. Une copie de fichier serveur doit rester privée. Notez la directive exacte, son emplacement, son périmètre et la manière de réappliquer l’ancienne valeur ; une capture de tout le panneau ne remplace pas cette information.

Choisissez la couche que les observations rendent plausible. Les trois parcours suivants concernent des environnements différents : PHP, le serveur web ou une extension déjà utilisée. Il n’est pas nécessaire de les exécuter tous. Après chaque changement, reprenez la même requête puis revenez à l’état initial si le test n’apporte rien.

1. Préparez de préférence une copie qui reproduit la chaîne concernée, avec paiements et envois externes neutralisés.
2. Relevez les en-têtes et le résultat avant toute modification.
3. Vérifiez les conséquences d’une purge ou d’un rechargement avec le responsable du service.
4. Changez un seul réglage dans le périmètre le plus étroit possible.
5. Comparez le résultat puis conservez ou annulez ce changement avant d’examiner une autre couche.

Tester la compression PHP lorsque cette couche est confirmée

Si l’hébergement confirme que PHP compresse déjà la sortie et qu’une autre couche intervient sur le même contenu, le responsable peut tester la désactivation de cette seule compression. Le réglage concerné est zlib.output_compression. Ne supposez pas sa valeur à partir du PHP utilisé dans un terminal : le site web peut employer une autre configuration.

Utilisez le réglage PHP du domaine ou le fichier INI effectivement chargé, selon les accès fournis. L’exemple ci-dessous remplace sa valeur existante. Une configuration .user.ini n’est pertinente que pour les modes CGI ou FastCGI qui la prennent en charge ; sa relecture peut être différée. Ne collez pas une directive php_flag dans un .htaccess sur un serveur dont le mode PHP n’est pas vérifié. Si un code utilise séparément le gestionnaire de sortie ob_gzhandler, la seule valeur de zlib.output_compression ne décrit pas toute la compression PHP ; faites vérifier ce code par son mainteneur sans ajouter une seconde gestion de sortie.

1. Relevez la valeur effective pour les requêtes web et sauvegardez le réglage initial.
2. Sur la copie ou le périmètre préparé, passez uniquement cette valeur à Off.
3. Faites appliquer la configuration selon le mécanisme du service, puis répétez la requête concernée.
4. Vérifiez aussi une réponse nouvellement générée, car une ancienne copie en cache peut rester inchangée.
5. Si le résultat ne change pas, rétablissez la valeur initiale avant un autre test.

zlib.output_compression = Off

Tester la compression dynamique Nginx dans le bon contexte

Ce parcours concerne le responsable ayant accès à la configuration Nginx effective du domaine. La directive ci-dessous désactive sa compression dynamique gzip dans le contexte où elle est placée, par exemple le bloc serveur du seul site concerné. Elle ne se colle ni dans wp-config.php ni dans .htaccess.

Corrigez la définition effective plutôt que d’ajouter des directives en plusieurs endroits. Si un panneau génère la configuration, utilisez son mécanisme prévu pour éviter qu’un enregistrement ultérieur efface le test. Le contexte et les éventuelles règles plus spécifiques doivent être examinés avec le responsable. Sur une copie isolée, utilisez le contexte existant du domaine. Ne créez pas un nouveau bloc location uniquement pour y coller ce test : sa priorité pourrait changer le routage WordPress ou empêcher l’exécution PHP attendue.

Après sauvegarde, contrôlez la configuration avec nginx -t, en conservant les paramètres habituels du service. Appliquez le changement par son rechargement prévu, par exemple nginx -s reload si ce mode est celui du service, uniquement si le contrôle réussit, puis comparez la même réponse. Si la syntaxe échoue, restaurez le fragment et ne rechargez pas une configuration invalide.

Cette directive n’arrête pas un module de fichiers précompressés comme gzip_static, ni une compression effectuée avant ou après Nginx. Une réponse toujours compressée n’établit donc pas que le réglage est ignoré. Identifiez la source restante ; si le test n’explique pas l’erreur, remettez la valeur précédente et rechargez selon la même procédure contrôlée.

gzip off;

Isoler mod_deflate sur un chemin Apache précis

Sur Apache confirmé, le responsable peut exclure un chemin de la compression mod_deflate avec une condition ciblée. L’exemple vise uniquement /page-test/ : remplacez ce chemin par celui de la ressource étudiée et adaptez l’expression si elle contient des caractères spéciaux. Il ne faut pas désactiver le module pour tous les domaines pour tester une seule page.

La directive exige mod_setenvif et un emplacement où elle est autorisée. Dans un .htaccess, l’autorisation de configuration doit permettre cette directive ; sinon une erreur serveur peut apparaître. Une règle liée au chemin peut aussi être affectée par les réécritures internes : le résultat doit être contrôlé sur la requête réelle. Le marqueur no-gzip vise mod_deflate ; il ne désactive ni Brotli, ni un fichier déjà compressé, ni la compression d’un intermédiaire.

Un contrôle apachectl configtest de la configuration serveur ne certifie pas les fichiers .htaccess, lus pendant les requêtes. Pour cette variante, conservez un accès SFTP ou au gestionnaire de fichiers afin de retirer immédiatement la seule ligne ajoutée si elle provoque une erreur. Effectuez l’essai sur la copie prévue ; ne remplacez pas l’ensemble du fichier ni les règles WordPress.

1. Sauvegardez le fichier actif en privé et ajoutez la condition dans le périmètre du site identifié.
2. Pour une modification de configuration serveur, utilisez apachectl configtest, puis le rechargement prévu, par exemple apachectl graceful pour ce mode de gestion, seulement après succès.
3. Rechargez la ressource et comparez le décodage ainsi que ses en-têtes.
4. En cas d’erreur ou d’absence d’effet utile, retirez la condition ajoutée et contrôlez le retour à l’état initial.
5. Si la réponse vient d’un cache ou d’une autre compression, examinez cette couche sans élargir aveuglément l’exclusion.

SetEnvIfNoCase Request_URI "^/page-test/$" no-gzip

Tester l’option de WP Super Cache déjà installé

WP Super Cache, extension gratuite d’Automattic, peut conserver des pages compressées. Ce parcours sert à isoler son réglage sur un site qui l’utilise déjà ; il ne justifie pas de l’installer pour diagnostiquer un autre cache. Vérifiez la compatibilité de la version présente avant toute intervention.

Ce parcours convient uniquement si elle est déjà active et si vous disposez des droits de réglage. Dans Réglages > WP Super Cache > Advanced, l’option anglaise est « Compress pages so they’re served more quickly to visitors. ». Sa traduction peut varier. Changer cette option vide le cache du produit. Faites donc cet essai uniquement sur une copie isolée, dont le stockage de cache est séparé de celui de la production. Ce guide ne propose pas cette bascule comme purge générale du site réel. Si la case n’apparaît pas, ne la forcez pas : elle dépend notamment des fonctions de compression disponibles et peut être désactivée par la configuration.

1. Notez l’état initial de la case et les conditions de la requête qui échoue.
2. Si la compression est active, décochez uniquement cette option et utilisez Update Status pour enregistrer. Relisez les messages et l’état conservé après rechargement de l’écran : une alerte liée à zlib.output_compression peut empêcher la bascule. Dans ce cas, arrêtez ce test et examinez la compression PHP avec le responsable.
3. Ouvrez l’adresse cible dans une session non connectée, puis rechargez pour comparer la réponse reconstruite.
4. Contrôlez le décodage et les en-têtes plutôt que la seule présence visuelle de la page.
5. Si cela ne change rien, rétablissez le réglage initial avec le même enregistrement, en tenant compte de la nouvelle purge.
6. Si cela résout l’échec, vérifiez quelle autre couche compresse et documentez le réglage retenu. La case ne pilote ni PHP, ni le proxy, ni le réseau de diffusion.

Régénérer les variantes après avoir corrigé la cause

Une configuration corrigée peut laisser une ancienne réponse incorrecte dans un cache situé plus loin. Invalidez alors uniquement la ressource concernée dans les couches où une ancienne copie est effectivement constatée, avec la procédure du service. Si aucune invalidation ciblée n’existe, demandez au responsable une stratégie de renouvellement adaptée ; ne remplacez pas cette étape par une suppression de tous les caches.

Conservez les dimensions qui distinguent les variantes : compression acceptée, langue, domaine et état de connexion. Une version publique corrigée ne doit pas être remplacée par une page personnalisée issue d’une session administrateur. Après purge, comparez une première génération et une nouvelle consultation de la même page.

Si la panne revient seulement après reconstruction ou sur un autre serveur, examinez la règle qui produit cette copie et la cohérence des configurations. Une purge répétée qui répare quelques minutes puis laisse revenir l’erreur indique qu’il reste une cause à traiter. Ne programmez pas des purges continues pour dissimuler ce comportement. Conservez les en-têtes avant et après, avec l’heure, pour que le responsable puisse retrouver la réponse dans ses journaux.

Vérifier les parcours qui doivent continuer de fonctionner

Le contrôle final porte sur le même navigateur et la même requête qui échouaient, puis sur quelques variantes représentatives. Une réponse sans compression peut convenir provisoirement si elle est complète et lisible ; la performance se réévalue ensuite, une fois la cohérence rétablie. N’activez pas plusieurs nouvelles optimisations pendant cette validation.

Une page HTML retrouvée ne suffit pas si ses scripts ou ses styles restent illisibles. Inversement, une erreur limitée à une réponse d’éditeur doit être reproduite dans son contexte sans publier un contenu réel pour le seul test. Sur la copie, utilisez un brouillon et neutralisez les effets externes.

1. Rechargez la page initialement affectée avec le panneau Réseau ouvert et vérifiez la disparition de l’erreur de décodage.
2. Contrôlez le document principal ainsi que les ressources importantes qu’il appelle.
3. Comparez une consultation fraîche et une consultation servie depuis le cache reconstruit.
4. Vérifiez les variantes de langue ou de chemin impliquées dans la panne, puis un parcours connecté autorisé.
5. Si curl a servi au diagnostic, répétez les deux demandes dans les mêmes conditions et archivez leurs résultats expurgés.

Annuler un test sans perdre la preuve de la panne

Si une modification aggrave le résultat ou n’apporte rien, rétablissez la valeur initiale dans sa source effective. Pour un fichier généré, corrigez le réglage producteur plutôt qu’une copie qui sera écrasée. Appliquez ensuite le contrôle de syntaxe et le mécanisme de rechargement propres au service concerné ; une ancienne valeur remise sur disque n’est pas forcément déjà active.

Le retour du réglage ne recrée pas instantanément les anciennes entrées de cache. Laissez la reconstruction prévue se faire et contrôlez sa charge avec le responsable si le site est fréquenté. Ne restaurez pas une ancienne base de données pour annuler uniquement une directive de compression lorsque aucune autre donnée n’a été modifiée.

Transmettez un dossier bref : adresse publique affectée, heure, statut, en-têtes utiles, couche testée, réglage initial, changement et résultat. Indiquez aussi si le défaut dépend d’une réponse en cache et si le navigateur et curl se comportent différemment. Cette preuve permet de poursuivre sur le composant précis, sans retirer toutes les protections ni supposer qu’une extension citée dans un forum produit la même panne sur tous les sites.