zOompf a effectué des recherches très approfondies sur ce sujet ici . Il l’emporte sur les résultats ci-dessous.
Définitions HTTP 1.1 de GZIP et DEFLATE (zlib) pour certaines informations d’arrière-plan:
“Gzip” est le format gzip, et “deflate” est le format zlib . Ils auraient probablement dû appeler le second “zlib” à la place pour éviter toute confusion avec le format de données compressées. Alors que le HTTP 1.1 RFC 2616 pointe correctement vers la spécification zlib de la RFC 1950 pour le codage de transfert «dégonfler», des serveurs et des navigateurs produisant ou prévoyant des données brutes de dégonflage incorrectes selon la spécification de dégonflement de la RFC 1951, notamment les produits Microsoft , ont été signalés. le codage de transfert utilisant le format zlib serait l’approche la plus efficace ( et en fait exactement ce que le format zlib a été conçu ), l’utilisation de l’encodage de transfert ‘gzip’ est probablement plus fiable en raison du choix malheureux du nom du HTTP 1.1 auteurs. ” (source: http://www.gzip.org/zlib/zlib_faq.html )
Donc, ma question: si j’envoie des données RAW déflatées avec NO zlib wrapper (ou gzip, d’ailleurs) y a-t-il des navigateurs modernes (par exemple, IE6 et plus, FF, Chrome, Safari, etc.) données compressées (en supposant que l’en-tête de requête HTTP “Accept-Encoding” contienne “deflate”)?
Les données de dégonflage seront TOUJOURS plus petites que GZIP.
Si tous ces navigateurs peuvent décoder les données avec succès, quels inconvénients y a-t-il à envoyer un dégonflage RAW au lieu de zlib?
Consultez http://www.vervestudios.co/projects/compression-tests/results pour plus de résultats.
Voici les navigateurs 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/AN/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 du DEFLATE brut (lorsque l’en-tête de requête HTTP “Accept-Encoding” contient “deflate”) et que le navigateur pourra interpréter correctement les données encodées. Quelqu’un peut-il prouver le contraire?
remarque: l’implémentation native de DEFLATE (System.IO.Compression.DeflateStream) de .NET est raw DEFLATE. Ça craint aussi. Veuillez utiliser zlib.net pour tous vos besoins de déflation .NET.
Le navigateur Android 1.6 (v4) échoue à la fois au test zlib et au test de dégonflage sur votre page. Je l’ai ajouté à votre liste.
N’est-ce pas le cas que AddOutputFilterByType DEFLATE
utilise mod_deflate envoie par gzip par défaut?
pour autant que je sache, oui – à peu près vous “pouvez toujours envoyer du DEFLATE brut et tout ira bien” … il n’y a pas “toujours”, mais la plupart des cas. sinon, c’est le problème du navigateur.