Dégonflez la compatibilité et les avantages du navigateur de compression par rapport à GZIP
MISE À JOUR 10 février 2012:
zOompf a effectué des recherches très approfondies sur ce même sujet ici . Il l'emporte sur toutes les conclusions ci-dessous.
MISE À JOUR 11 septembre 2010:
Une plateforme de test a été créée pour cela ici
Définitions HTTP 1.1 de GZIP et DEFLATE (zlib) pour quelques informations générales:
"'Gzip' est le format gzip, et 'deflate' est le format zlib . Ils auraient probablement dû appeler le second 'zlib' à la place pour éviter confusion avec le format de données compressé dégonflé brut. Alors que le HTTP 1.1 RFC 2616 pointe correctement vers la spécification zlib dans RFC 1950 pour le codage de transfert "dégonfler", il y a eu des rapports de serveurs et de navigateurs qui produire ou attendre incorrectement des données brutes de dégonflage selon la spécification de dégonflage dans la RFC 1951, plus particulièrement les produits Microsoft. format serait l'approche la plus efficace ( et en fait exactement à quoi le format zlib a été conçu ), en utilisant le L'encodage de transfert 'gzip' est probablement plus fiable en raison d'un choix malheureux 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 de dégonflage RAW avec NO zlib wrapper (ou gzip, d'ailleurs), y a-t-il des navigateurs modernes (par exemple, IE6 et plus, FF, Chrome, Safari, etc.) qui ne peuvent PAS comprendre le dégonflage brut données compressées (en supposant que l'en-tête de requête HTTP "Accept-Encoding" contient "deflate")?
Les données de dégonflage seront TOUJOURS plus petites de quelques octets que GZIP.
Si tous ces navigateurs peuvent décoder les données avec succès, quels sont les inconvénients à envoyer un dégonflage RAW au lieu de zlib?
MISE À JOUR 11 septembre 2010:
Une plateforme de test a été créée pour cela ici
MISE À JOUR: les navigateurs ont abandonné la prise en charge du dégonflage brut. zOompf a effectué des recherches très approfondies sur ce même sujet ici . Malheureusement, il semble que le dégonflage brut ne soit PAS sûr à utiliser.
Vérifiez 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 l'en-tête de requête HTTP "Accept-Encoding: gzip". Le dégonflage n'est pas autorisé.
Je conclus que nous pouvons toujours envoyer raw DEFLATE (lorsque l'en-tête de requête HTTP "Accept- L'encodage "contient" dégonfler ") et le navigateur pourra interpréter correctement les données encodées. Quelqu'un peut-il prouver le contraire?
note: l'implémentation native de .NET de DEFLATE (System.IO.Compression.DeflateStream) est une DEFLATE brute. Ça craint aussi. Veuillez utiliser zlib.net pour tous vos besoins de dégonflage .NET.
Le navigateur Android 1.6 (v4) échoue à la fois le test zlib et le test de dégonflage sur votre page. Je l'ai ajouté à votre liste.
N'est-il pas vrai que AddOutputFilterByType DEFLATE utiliser mod_deflate envoie par gzip par défaut?