Quelle est la cause de ERR_CONTENT_DECODING_FAILED dans Chrome ?

Cette erreur se produit lorsque les en-têtes de réponse HTTP indiquent que le contenu est encodé en gzip (Content-Encoding: gzip) mais que le corps réel de la réponse n'est pas des données gzip valides. Les causes courantes incluent un plugin d'application web compressant le contenu alors que le serveur web applique également la compression gzip (double encodage), des proxys inverses mal configurés qui suppriment la compression mais ne mettent pas à jour les en-têtes, ou des réponses mises en cache corrompues.

Comment corriger ERR_CONTENT_DECODING_FAILED sur IIS ?

Dans le Gestionnaire IIS, vérifiez vos paramètres de compression dans la Vue des fonctionnalités au niveau du serveur. Si un plugin WordPress ou l'application gère la compression, désactivez la compression dynamique d'IIS pour éviter le double encodage. Alternativement, désactivez la compression dans l'application et laissez IIS la gérer. Vous pouvez également vérifier le web.config pour des paramètres httpCompression conflictuels.

Vider le cache du navigateur corrige-t-il ERR_CONTENT_DECODING_FAILED ?

Vider le cache corrige l'erreur uniquement si le problème était une réponse mise en cache corrompue. Si le serveur est activement mal configuré, l'erreur reviendra à la prochaine requête. Videz le cache pour écarter la corruption (Ctrl+Shift+Suppr dans Chrome), puis vérifiez si l'erreur persiste. Si c'est le cas, la configuration du serveur ou du proxy doit être corrigée.

Que signifie l'Erreur 330 (net::ERR_CONTENT_DECODING_FAILED) dans Google Chrome

L’erreur ERR_CONTENT_DECODING_FAILED (parfois affichée comme Erreur 330 dans les anciennes versions de Chrome) apparaît lorsque Google Chrome ne peut pas décoder le contenu reçu d’un serveur web. Cela signifie généralement que les en-têtes de réponse HTTP du serveur indiquent que le contenu est compressé (habituellement avec gzip), mais le corps réel de la réponse n’est pas compressé, est compressé différemment ou est corrompu. Cet article explique les causes racines, comment diagnostiquer le problème et comment le corriger sur différentes plateformes de serveur web.

Comprendre l’erreur

Lorsqu’un navigateur envoie une requête à un serveur web, il inclut un en-tête Accept-Encoding indiquant les méthodes de compression qu’il prend en charge :

Accept-Encoding: gzip, deflate, br

Si le serveur décide de compresser la réponse, il inclut un en-tête Content-Encoding dans la réponse :

Content-Encoding: gzip

Le navigateur s’attend alors à décompresser le corps de la réponse en utilisant l’algorithme spécifié. ERR_CONTENT_DECODING_FAILED se produit lorsqu’il y a une incohérence — l’en-tête dit gzip mais le corps n’est pas des données gzip valides.

Causes courantes

Double compression (la plus courante)

C’est la cause la plus fréquente, en particulier avec les plateformes CMS comme WordPress. Cela se produit lorsque :

Un plugin de cache ou d’optimisation WordPress active la compression gzip au niveau de l’application
Le serveur web (IIS, Nginx, Apache) est également configuré pour compresser les réponses
Le serveur compresse le contenu déjà compressé, produisant des données gzip invalides
Chrome reçoit les données doublement compressées et ne parvient pas à les décoder

Interférence de proxy ou CDN

Un proxy inverse ou CDN entre le client et le serveur d’origine peut :

Supprimer le contenu compressé mais laisser l’en-tête Content-Encoding: gzip intact
Recompresser une réponse déjà compressée
Mettre en cache une réponse compressée et la servir avec des en-têtes incorrects

Réponse corrompue

Des problèmes réseau, des réponses tronquées ou des erreurs côté serveur peuvent produire une réponse où l’en-tête Content-Encoding est défini mais le corps est incomplet ou corrompu.

Logiciel antivirus ou de sécurité

Un logiciel antivirus de bureau qui inspecte le trafic HTTPS peut parfois modifier les corps de réponse sans mettre à jour les en-têtes d’encodage de contenu, provoquant l’échec du décodage par le navigateur.

Diagnostiquer le problème

Utiliser les outils de développement Chrome

Appuyez sur F12 pour ouvrir les Outils de développement Chrome
Allez dans l’onglet Réseau
Rechargez la page qui produit l’erreur
Cliquez sur la requête échouée
Examinez les En-têtes de réponse :
- Recherchez Content-Encoding: gzip
- Vérifiez Transfer-Encoding
Cliquez sur l’onglet Réponse — si la réponse est illisible ou vide, l’encodage est incorrect

Utiliser curl depuis la ligne de commande

# Request with gzip encoding and see response headers
curl -H "Accept-Encoding: gzip" -I https://example.com

# Download the response and check if it is valid gzip
curl -H "Accept-Encoding: gzip" -o response.gz https://example.com
file response.gz    # Should report "gzip compressed data"
gunzip response.gz  # Should decompress without errors

# Request without compression to see if the page works
curl --compressed -v https://example.com

Vérifier avec un autre navigateur

Si la page se charge dans Firefox ou Edge mais pas dans Chrome, le problème peut être lié au cache de Chrome ou à une extension spécifique à Chrome. Si cela échoue dans tous les navigateurs, le problème est côté serveur.

Corriger le problème sur IIS

Désactiver la double compression

Si un plugin WordPress ou l’application PHP gère la compression, désactivez la compression dynamique d’IIS :

En utilisant le Gestionnaire IIS :

Ouvrez le Gestionnaire IIS
Sélectionnez le site ou le nœud du serveur
Double-cliquez sur Compression
Décochez Activer la compression de contenu dynamique
Cliquez sur Appliquer

En utilisant web.config :

<configuration>
  <system.webServer>
    <urlCompression doStaticCompression="true"
                    doDynamicCompression="false" />
  </system.webServer>
</configuration>

Ou laissez IIS gérer toute la compression

Alternativement, désactivez la compression dans l’application et laissez IIS la gérer :

Désactivez le gzip dans les plugins WordPress (W3 Total Cache, WP Super Cache, etc.)
Activez la compression statique et dynamique dans IIS :

<configuration>
  <system.webServer>
    <urlCompression doStaticCompression="true"
                    doDynamicCompression="true" />
    <httpCompression>
      <dynamicTypes>
        <add mimeType="text/*" enabled="true" />
        <add mimeType="application/javascript" enabled="true" />
        <add mimeType="application/json" enabled="true" />
        <add mimeType="*/*" enabled="false" />
      </dynamicTypes>
      <staticTypes>
        <add mimeType="text/*" enabled="true" />
        <add mimeType="application/javascript" enabled="true" />
        <add mimeType="*/*" enabled="false" />
      </staticTypes>
    </httpCompression>
  </system.webServer>
</configuration>

Corriger le problème sur Nginx

Vérifier la configuration gzip

Vérifiez votre configuration Nginx pour des paramètres gzip corrects :

http {
    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_min_length 1000;

    gzip_types
        text/plain
        text/css
        text/xml
        text/javascript
        application/json
        application/javascript
        application/xml
        application/xml+rss
        application/x-javascript
        image/svg+xml;
}

Éviter de compresser du contenu déjà compressé

Si votre application (PHP, Node.js) envoie des réponses pré-compressées, indiquez à Nginx de ne pas les compresser à nouveau :

location ~ \.php$ {
    # Pass through without additional compression
    gzip off;
    proxy_pass http://backend;
}

Ou utilisez gzip_proxied pour contrôler quand Nginx compresse les réponses du proxy :

# Only compress if the backend did not already compress
gzip_proxied no-cache no-store private expired auth;

Corriger le problème sur Apache

Vérifier la configuration conflictuelle de mod_deflate

# In .htaccess or httpd.conf
<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml
    AddOutputFilterByType DEFLATE text/css text/javascript
    AddOutputFilterByType DEFLATE application/json application/javascript
    AddOutputFilterByType DEFLATE application/xml application/xhtml+xml

    # Do not compress images or already-compressed files
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|gz|zip|bz2)$ no-gzip
</IfModule>

Si un plugin PHP compresse également la sortie, désactivez mod_deflate ou désactivez la compression du plugin.

Solutions spécifiques à WordPress

Comme cette erreur se produit fréquemment avec les installations WordPress, voici des corrections ciblées :

W3 Total Cache

Allez dans Performances > Cache du navigateur
Sous Compression HTTP, décochez Activer la compression HTTP (gzip)
Enregistrez les paramètres
Laissez le serveur web gérer la compression à la place

WP Super Cache

Allez dans Réglages > WP Super Cache > Avancé
Décochez Compresser les pages pour qu’elles soient servies plus rapidement aux visiteurs
Enregistrez les paramètres

Modification du wp-config.php

Vous pouvez ajouter ceci dans wp-config.php pour empêcher WordPress d’envoyer une sortie compressée :

// Disable WordPress gzip output
@ini_set('zlib.output_compression', 'Off');

Dépannage côté client

Si vous rencontrez cette erreur en tant qu’utilisateur (pas en tant qu’administrateur du serveur) :

Vider le cache du navigateur

Appuyez sur Ctrl+Shift+Suppr dans Chrome
Sélectionnez Images et fichiers en cache
Définissez la période sur Toutes les périodes
Cliquez sur Effacer les données

Désactiver les extensions du navigateur

Certaines extensions (bloqueurs de publicités, outils de confidentialité) peuvent interférer avec le traitement des réponses :

Ouvrez chrome://extensions/
Désactivez toutes les extensions
Rechargez la page qui échoue
Si cela fonctionne, réactivez les extensions une par une pour trouver la coupable

Vérifier l’analyse HTTPS de l’antivirus

Si votre antivirus analyse le trafic HTTPS, essayez de désactiver temporairement cette fonctionnalité pour voir si cela résout l’erreur.

Vider le cache DNS

ipconfig /flushdns

Sur macOS :

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Résumé

L’erreur ERR_CONTENT_DECODING_FAILED dans Chrome est causée par une incohérence entre l’en-tête Content-Encoding et le corps réel de la réponse. La cause la plus courante est la double compression, où un plugin CMS et le serveur web tentent tous deux de compresser la réponse en gzip. La solution est simple : assurez-vous qu’une seule couche gère la compression. Utilisez les Outils de développement Chrome et curl pour diagnostiquer quelle couche cause le conflit, puis ajustez la configuration d’IIS, Nginx ou Apache en conséquence. Pour WordPress spécifiquement, désactivez la compression dans les plugins de cache et laissez le serveur web la gérer.