Compatibilité et avantages du navigateur de compression Deflate par rapport à GZIP
mettre à JOUR le 10 Février 2012:
zOompf a terminé quelques recherches très approfondies sur ce même sujet ici . Il surpasse toutes les conclusions ci-dessous.
mise à JOUR des attentats du 11 Septembre 2010:
une plate-forme d'essai a été créée pour ce ici
HTTP 1.1 définitions de GZIP et DEFLATE (zlib) pour des informations sur le contexte:
" 'Gzip' est le format gzip, et 'deflate' est la zlib format . Ils aurait probablement dû appeler le deuxième "zlib" à la place d'éviter confusion avec le format raw deflate compressed data. Alors que le HTTP 1.1 la RFC 2616 renvoie correctement à la spécification zlib de la RFC 1950 pour le 'deflate' transfert encodage, Il ya eu des rapports de les serveurs et les navigateurs qui produisent ou s'attendent à produire incorrectement deflate raw données selon la spécification deflate dans la RFC 1951, , notamment Les produits Microsoft . Ainsi, même si l'encodage de transfert "deflate" le format zlib serait l'approche la plus efficace ( et en fait exactement ce que le format zlib a été conçu pour ), en utilisant le 'gzip' transfert l'encodage est probablement plus fiable en raison d'un mauvais choix de nom de la part des auteurs HTTP 1.1."(source: http://www.gzip.org/zlib/zlib_faq.html )
donc, ma question: si j'envoie des données brutes deflate sans zlib wrapper (ou gzip, pour cette question) des navigateurs modernes (par exemple, IE6 et FF, Chrome, Safari, etc) qui ne peuvent pas comprendre le déflate brut données compressées (en supposant que L'en-tête de requête HTTP "Accept-Encoding"" contient "dégonfler")?
Dégonfler données seront TOUJOURS quelques octets de plus petite que GZIP.
si tous ces navigateurs peuvent décoder avec succès les données, ce que y a-t-il des inconvénients à envoyer du deflate brut au lieu de zlib?
mise à jour 11 septembre 2010:
une plate-forme d'essai a été créée pour ce ici
4 réponses
mise à jour: les navigateurs ont abandonné le support pour deflate brut. zOompf a réalisé des recherches très approfondies sur ce même sujet ici . malheureusement, il semble que le deflate brut ne soit pas sûr à utiliser.
vérifier http://www.vervestudios.co/projects/compression-tests/results pour plus de résultats.
Voici les navigateurs qui ont été testés:
/* Browser DEFLATE ZLIB */
XP Internet Explorer 6 PASS FAIL
XP Internet Explorer 7 PASS FAIL
XP Internet Explorer 8 PASS FAIL
Vista Internet Explorer 8 PASS FAIL
XP Firefox 3.6.* PASS PASS
XP Firefox 3.5.3 PASS PASS
XP Firefox 3.0.14 PASS PASS
Win 7 Firefox 3.6.* PASS PASS
Vista Firefox 3.6.* PASS PASS
Vista Firefox 3.5.3 PASS PASS
XP Safari 3 PASS PASS
XP Safari 4 PASS PASS
XP Chrome 3.0.195.27 PASS PASS
XP Opera 9 PASS PASS
XP Opera 10 PASS PASS
XP Sea Monkey 1.1.8 PASS PASS
Android 1.6 Browser (v4)* N/A N/A
OS-X Safari 4 PASS PASS
OS X Chrome 7.0.517.44 PASS PASS
OS X Opera 10.63 PASS PASS
iPhone 3.1 Safari PASS PASS
* Android Envoie-tête de requête HTTP "Accept-Encoding: gzip". Dégonfler n'est pas autorisée.
Je conclus que nous pouvons toujours envoyer raw DEFLATE (lorsque L'en-tête de requête HTTP " Accept-Encoding "contient" deflate") et le navigateur sera en mesure de correctement interpréter les données codées. Quelqu'un peut-il prouver que c'est mal?
note: L'implémentation native de DEFLATE (System.IO.Compression.DeflateStream) est un DÉFLATE brut. Elle suce aussi. Veuillez utiliser zlib.net pour tous vos besoins de dégonflage.
le navigateur Android 1.6 (v4) échoue à la fois le test zlib et le test deflate sur votre page. Je l'ai ajouté à votre liste.
N'est-ce pas le cas que AddOutputFilterByType DEFLATE utilisant mod_deflate envoie par gzip par défaut?
autant que je sache, oui - à peu près vous "pouvez toujours envoyer DEFLATE brut et tout irait bien"... il n'y a pas "toujours", mais la plupart des cas. si non, c'est le navigateur du problème.