Zmniejsz kompatybilność przeglądarki kompresji i zalety w stosunku do GZIP
zOompf ukończył bardzo szczegółowe badania na ten temattutaj. Przeważa wszelkie ustalenia poniżej.
Definicje HTTP 1.1 GZIP i DEFLATE (zlib) dla niektórych podstawowych informacji:
„Gzip” to format gzip i„deflate” to format zlib. Powinni oni prawdopodobnie wywołać drugi „zlib”, aby uniknąć nieporozumień z nieprzetworzonym formatem skompresowanych danych. Podczas gdy RFC 2616 HTTP 1.1 poprawnie wskazuje specyfikację zlib w RFC 1950 dla kodowania transferu „deflate”,pojawiły się raporty o serwerach i przeglądarkach, które niepoprawnie produkują lub oczekują nieprzetworzonych danych deflacji według specyfikacji deflate w RFC 1951,przede wszystkim produkty Microsoft. Więc nawet jeśli kodowanie transferu „deflate” z wykorzystaniem formatu zlib byłoby bardziej wydajnym podejściem (a właściwie dokładniedo czego został zaprojektowany format zlib), użycie kodowania transferu „gzip” jest prawdopodobnie bardziej niezawodne z powodu niefortunnego wyboru nazwy przez autorów HTTP 1.1. ”(źródło:http://www.gzip.org/zlib/zlib_faq.html)
Tak więc, moje pytanie: jeśli wysyłam RAW deflate dane z NO wrapper zlib (lub gzip, o to chodzi), czy są jakieś nowoczesne przeglądarki (np. IE6 i nowsze, FF, Chrome, Safari, itp.), Które NIE mogą zrozumieć surowej deflacji skompresowane dane (zakładając, że nagłówek żądania HTTP „Accept-Encoding” zawiera „deflate”)?
Dane deflacji ZAWSZE będą o kilka bajtów mniejsze niż GZIP.
Jeśli wszystkie te przeglądarki mogą z powodzeniem dekodować dane, jakie są wady wysyłania deflacji RAW zamiast zlib?