UPDATE 10. Februar 2012:
zOompf hat hier zu diesem Thema einige sehr gründliche Untersuchungen durchgeführt . Es übertrumpft alle Befunde unten.
UPDATE 11. September 2010:
Eine Testplattform wurde speziell für diese erstellt hier
HTTP 1.1-Definitionen von GZIP und DEFLATE (zlib) für einige Hintergrundinformationen:
"'Gzip' ist das gzip-Format und 'deflate' ist das zlib-Format . Sie hätten wahrscheinlich stattdessen das zweite 'zlib' nennen sollen, um Verwechslungen mit dem komprimierten Raw-Deflate-Datenformat zu vermeiden. Während der HTTP 1.1 RFC 2616 korrekt darauf verweist In der zlib-Spezifikation in RFC 1950 für die Übertragungscodierung "Deflate" wurden Berichte über Server und Browser veröffentlicht, die gemäß der Deflate-Spezifikation in RFC 1951 fälschlicherweise Deflate-Rohdaten erzeugen oder erwarten, insbesondere Microsoft-Produkte . Die Übertragungscodierung im Zlib-Format wäre der effizientere Ansatz ( und genau das , wofür das Zlib-Format entwickelt wurde) ist die Verwendung der 'gzip'-Übertragungscodierung aufgrund einer unglücklichen Namenswahl seitens der HTTP 1.1-Autoren wahrscheinlich zuverlässiger. "(Quelle: http://www.gzip.org/zlib/zlib_faq.html )
Meine Frage: Wenn ich RAW-Deflate-Daten ohne Zlib-Wrapper (oder gzip) sende, gibt es moderne Browser (z. B. IE6 und höher, FF, Chrome, Safari usw.), die die Roh-Deflate NICHT verstehen können komprimierte Daten (unter der Annahme, dass der HTTP-Anforderungsheader "Accept-Encoding" "deflate" enthält)?
Deflate-Daten sind IMMER einige Bytes kleiner als GZIP.
Wenn alle diese Browser die Daten erfolgreich dekodieren können, welche Nachteile hat das Senden von RAW-Deflate anstelle von zlib?
UPDATE 11. September 2010:
Eine Testplattform wurde speziell für diese erstellt hier
quelle
Antworten:
UPDATE: Browser haben die Unterstützung für Raw Deflate eingestellt. zOompf hat hier zu diesem Thema einige sehr gründliche Untersuchungen durchgeführt . Leider scheint es, dass Rohdeflat NICHT sicher zu verwenden ist.
Weitere Ergebnisse finden Sie unter http://www.vervestudios.co/projects/compression-tests/results .Hier sind die getesteten Browser:* Android Sendet den HTTP-Anforderungsheader "Accept-Encoding: gzip". Entleeren ist nicht erlaubt.
Ich komme zu dem Schluss, dass wir immer roh senden können komme zu dem DEFLATE (wenn der HTTP-Anforderungsheader "Accept-Encoding" "Deflate" enthält) und der Browser die codierten Daten korrekt interpretieren kann. Kann jemand das falsch beweisen?
Hinweis: Die native Implementierung von DEFLATE (System.IO.Compression.DeflateStream) in .NET ist unformatiertes DEFLATE. Es ist auch scheiße. Bitte verwenden Sie zlib.net für alle Ihre .NET-Deflationsanforderungen.quelle
Der Android 1.6-Browser (v4) besteht sowohl den zlib- als auch den Deflate-Test auf Ihrer Seite nicht. Ich habe es Ihrer Liste hinzugefügt.
quelle
Ist es nicht so, dass die
AddOutputFilterByType DEFLATE
Verwendung von mod_deflate standardmäßig per gzip gesendet wird?quelle
AddOutputFilertByType DEFLATE
gzips die Antwort, anstatt sie standardmäßig zu entleeren (soweit ich weiß).Gzip
istdeflate
+ ein 10-Byte-Header + 8-Byte-Fußzeile - was bedeutet, dassGzip
das IMMER größer sein wird alsdeflate
... warum sollten wir also jemals gzip verwenden? ( Eine Aufschlüsselung der Bestandteile von gzip finden Sie unter en.wikipedia.org/wiki/Gzip#File_format .) Vor diesem Hintergrund bin ich mir nicht sicher, wie ichdeflate
die bevorzugte Komprimierungsmethode in Apache festlegen soll.Soweit ich weiß, ja - so ziemlich Sie "können immer rohe DEFLATE senden und alles wäre in Ordnung" ... es gibt nicht "immer", aber vor allem Fälle. Wenn nicht, ist dies das Problem des Browsers.
quelle
deflate
(dh nicht zlib , überhaupt keine Header) funktioniert in IE7 nur, wennencoding:gzip
und (nur in Chrome v24 getestet)encoding:deflate
in Chrome .