2012 年 2 月 10 日更新:
zOompf は、まさにこのトピックに関する非常に徹底的な調査を完了しました。これは、以下の調査結果よりも優先されます。
2010 年 9 月 11 日更新:
このためのテスト プラットフォームが作成されました。
背景情報については、GZIP および DEFLATE (zlib) の HTTP 1.1 定義を参照してください。
「「Gzip」は gzip 形式で、「deflate」は zlib 形式です。生の deflate 圧縮データ形式との混同を避けるために、おそらく 2 番目のものを「zlib」と呼ぶべきでした。HTTP 1.1 RFC 2616 は正しく「deflate」転送エンコーディングに関する RFC 1950 の zlib 仕様に基づいているため、RFC 1951 の deflate 仕様に従って生の deflate データを誤って生成または予期するサーバーとブラウザの報告があり、最も顕著なのは Microsoft 製品です。 zlib 形式を使用した転送エンコーディングは、より効率的なアプローチになります (実際 、zlib 形式が設計された目的はまさにそれです)。)、「gzip」転送エンコーディングを使用する方が、HTTP 1.1 作成者側の不幸な名前の選択により、おそらくより信頼性が高くなります。" (ソース: http://www.gzip.org/zlib/zlib_faq.html )
それで、私の質問: zlib ラッパー (または gzip など) なしで RAW deflate データを送信した場合、生の deflate を理解できない最新のブラウザー (IE6 以降、FF、Chrome、Safari など) はありますか?圧縮データ (HTTP 要求ヘッダー「Accept-Encoding」に「deflate」が含まれていると仮定)?
Deflate データは常に GZIP よりも数バイト小さくなります。
これらすべてのブラウザーがデータを正常にデコードできる場合、zlib の代わりに RAW deflate を送信することにはどのような欠点がありますか?