Sfiora la compatibilità del browser di compressione e i vantaggi rispetto a GZIP


AGGIORNAMENTO 10 febbraio 2012:

zOompf ha completato alcune ricerche molto approfondite su questo argomento qui . Trionfa qualsiasi risultato qui sotto.


AGGIORNAMENTO 11 settembre 2010:

Una piattaforma di test è stata creata per questo qui


Definizioni HTTP 1.1 di GZIP e DEFLATE (zlib) per alcune informazioni di base:

“‘Gzip’ è il formato gzip, e deflate‘ è il formato zlib.Avrebbero probabilmente chiamato il secondo ‘zlib’ invece di evitare confusione con il formato di dati compresso dello svuotamento grezzo mentre l’HTTP 1.1 RFC 2616 punta correttamente a le specifiche zlib in RFC 1950 per la codifica del trasferimento “deflate”, ci sono state segnalazioni di server e browser che producono in modo errato o si aspettano dati di svuotamento grezzi secondo le specifiche di deflate in RFC 1951, in particolare i prodotti Microsoft . trasferire la codifica utilizzando il formato zlib sarebbe l’approccio più efficiente ( e in effetti esattamente quello per cui è stato progettato il formato zlib ), l’uso della codifica di trasferimento ‘gzip’ è probabilmente più affidabile a causa di una scelta sfavorevole del nome da parte dell’HTTP 1.1 autori. ” (fonte: http://www.gzip.org/zlib/zlib_faq.html )

Quindi, la mia domanda: se invio dati RAW sgonfiati con NO wrapper zlib (o gzip, se è per questo) ci sono dei browser moderni (es. IE6 e versioni successive, FF, Chrome, Safari, ecc.) Che NON riescono a capire il grezzo sgonfio dati compressi (supponendo che l’intestazione della richiesta HTTP “Accept-Encoding” contenga “deflate”)?

I dati di sgonfiaggio saranno SEMPRE di qualche byte più piccoli di GZIP.

Se tutti questi browser sono in grado di decodificare i dati con successo, quali sono i lati negativi per l’invio di deflate RAW invece di zlib?

AGGIORNAMENTO 11 settembre 2010:

Una piattaforma di test è stata creata per questo qui

AGGIORNAMENTO: i browser hanno abbandonato il supporto per lo svuotamento grezzo. zOompf ha completato alcune ricerche molto approfondite su questo argomento . Sfortunatamente, sembra che lo sgonfio non sia sicuro da usare.


Controlla http://www.vervestudios.co/projects/compression-tests/results per ulteriori risultati.

Ecco i browser che sono stati testati:

/* 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 Invia l’intestazione della richiesta HTTP “Accept-Encoding: gzip”. Deflate non è permesso.

Concludo che possiamo sempre inviare raw DEFLATE (quando l’intestazione della richiesta HTTP “Accept-Encoding” contiene “deflate”) e il browser sarà in grado di interpretare correttamente i dati codificati. Qualcuno può dimostrarlo sbagliato?

nota: l’implementazione nativa di .NET di DEFLATE (System.IO.Compression.DeflateStream) è raw DEFLATE. Fa anche schifo. Si prega di utilizzare zlib.net per tutte le vostre esigenze di deflazione .NET.

Il browser Android 1.6 (v4) ha esito negativo sia sul test di zlib che di deflate sulla tua pagina. L’ho aggiunto alla tua lista.

Non è il caso che AddOutputFilterByType DEFLATE usa mod_deflate manda per gzip di default?

per quanto ne so, sì – praticamente tu “puoi sempre inviare DEFLATE grezzo e tutto andrebbe bene” … non c’è “sempre”, ma soprattutto casi. in caso contrario, questo è il problema del browser.