Les raisons pour lesquelles le contenu gzip pourrait ne pas être grokked par le navigateur

Question

Je tente de servir des ressources statiques (javascript) et css en tant que fichiers gzip mises en cache pour des raisons de performance.

Les pages semblent au format gzip lors du rendu, le Content-encoding est correctement gzip selon LiveHTTPHeaders, et surtout, le contenu gzip passe la page GIDZipTest ( http://www.gidnetwork.com/tools/gzip-test.php ) très bien. Voici un exemple de la sortie du test:

  

Web compressé? Oui

     

Type de compression? gzip

     

Taille, Markup (octets) 18286

     

Taille compressée (octets) 4427

     

Compression% 75,8

----

  

ResponseHeaders

     

état HTTP / 1.0 200 OK

     

pragma no-cache cache-control     privé, max-age = 86500

     

expires Lun 24 août 2009 04:34:14 GMT

     

x-amz-acl public-lu

     

texte type de contenu / css

     

content-md5 hqJaTBS3OzDFet / QHsd + Qg ==

     

gzip de codage de contenu

     

mer, 19 août 2009 04:34:14 GMT

     

serveur - mon serveur -

     

Longueur de contenu 4427

L'en-tête de codage de contenu est en gras, et tous les autres en-têtes sont comme prévu.

La page de test montre également la page source non compressée, et il est toujours exactement comme je pense que ce soit non compressé, et je l'ai même essayé de copier-coller à rendre par le navigateur, et il fonctionne, de sorte que le problème doit être à l'étape réelle de reconnaître que la page est gzip et décompresser.

Et ce n'est pas spécifique au navigateur. Dans FF, Webkit et IE, ces fichiers gzip ne sont pas décompressés correctement. J'ai tout essayé je peux penser, mais je suis vraiment perplexe.

Answer 1

Peut-être que vous avez quelque chose d'autre gzipping le fichier une deuxième fois, mais seulement pour les clients HTTP 1.1 qui liste dans Accept-Encoding, comme la plupart des navigateurs. GIDZipTest envoie les demandes HTTP 1.0 et 1.0 gzipping à des clients est risqué, car le protocole HTTP 1.0 n'a pas pour les clients d'indiquer qui encodages qu'ils prennent en charge le codage de champ accepter, il aurait du sens pour le second compresseur (s'il y a un ) à ne pas gzip à 1,0 clients. Si tel est le cas, GIDZipTest obtiendrait une réponse unique gzip alors que les navigateurs obtiendraient une réponse double gzip (mauvais). C'est juste une possibilité bien. Rare, mais il arrive.

Si ce n'est pas, vous devriez vraiment donner plus d'informations, comme une URL vers une page présentant le problème.

Answer 2

J'ai débogués un problème similaire au cours des deux dernières jours. Tous les html, css et js fichiers dans mon projet sont gzip. Il a bien fonctionné jusqu'à ce que Firefox 3.5 est arrivé. Firefox 3.0 et IE 7 + 8 n'a pas eu aucun problème. Oh et Opera 9 + 10 et Chrome étranglée sur le codage ainsi.

Les symptômes étaient des fichiers html et css sont reconnus correctement, seuls les fichiers js avaient le problème. Firebug me donne ce message d'erreur:

Étiquette non valide

Content-Encoding: gzip \ n

La solution pour moi était de retirer le doctype. Je l'ai essayé et lâche stricte et ne travaille. Mais je voudrais savoir ce que le DOCTYPE est.