AGGIORNAMENTO 10 febbraio 2012:
zOompf ha completato alcune ricerche molto approfondite su questo argomento qui . Supera qualsiasi risultato di seguito.
AGGIORNAMENTO 11 settembre 2010:
Una piattaforma di test è stato creato 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 . Probabilmente avrebbero dovuto chiamare il secondo" zlib "per evitare confusione con il formato di dati compressi deflate grezzo. Mentre HTTP 1.1 RFC 2616 punta correttamente a la specifica zlib in RFC 1950 per la codifica di trasferimento "deflate", sono stati segnalati server e browser che producono in modo errato o si aspettano dati di deflazione non elaborati secondo la specifica deflate in RFC 1951, in particolare i prodotti Microsoft . Quindi, anche se il "deflate" trasferire la codifica utilizzando il formato zlib sarebbe l'approccio più efficiente ( e in effetti esattamente per cosa è stato progettato il formato zlib), l'uso della codifica di trasferimento "gzip" è probabilmente più affidabile a causa di una scelta sfortunata del nome da parte degli autori di HTTP 1.1. "(fonte: http://www.gzip.org/zlib/zlib_faq.html )
Quindi, la mia domanda: se invio dati RAW deflate senza zlib wrapper (o gzip, se è per questo) ci sono browser moderni (ad esempio, IE6 e versioni successive, FF, Chrome, Safari, ecc.) Che NON possono comprendere il raw deflate dati compressi (supponendo che l'intestazione della richiesta HTTP "Accept-Encoding" contenga "deflate")?
I dati di deflate saranno SEMPRE di qualche byte più piccoli di GZIP.
Se tutti questi browser riescono a decodificare i dati con successo, quali svantaggi ci sono nell'inviare RAW deflate invece di zlib?