23

次のように、gzip 圧縮を使用して静的コンテンツを提供するように Web サイトを構成しています。

<link rel='stylesheet' href='http://cdn-domain.com/css/style.css.gzip?ver=0.9' type='text/css' media='all' />

同様のことをしているウェブサイトは見当たりません。では、問題は、これの何が問題なのかということです。私は欠点を期待していますか？

Accept-Encoding: gzip正確には、私が理解しているように、ほとんどの Web サイトは、リクエストにヘッダーが含まれている場合にのみ、通常の静的ファイル (.css、.js など) と gzip されたコンテンツ (.css.gz、.js.gz など) を提供するように構成されています。すべてのブラウザがまったくgzip同じものをサポートしているのに、なぜこれを行う必要があるのでしょうか?

PS:すべての静的コンテンツは CDN にアップロードする前に gzip され、gzip されたファイルを提供するだけなので、パフォーマンスの問題はまったく見られません。したがって、サーバーにストレス/負担はありません。

参考までに、gzip 圧縮された CSS ファイルの HTTP 応答ヘッダー情報を次に示します。

スクリーンショット 1

そして、これは gzip された favicon.ico ファイルの場合:

スクリーンショット 2

4

1 に答える 1

30

サポートContent-Encoding: gzipは、現在の HTTP 仕様の要件ではありません。そのため、リクエスト ヘッダーの形式でトリガーが存在します。

実際には？視聴者が Web ブラウザーを使用していて、正当なユーザーだけを心配している場合、前処理された gzip されたバージョンを利用できるだけで、実際に誰かが影響を受ける可能性はほとんどありません。過ぎ去った時代の名残りです。最近のブラウザーは、提供されているコンテンツの正しいヘッダーを提供している限り、リクエストしていなくても、gzip で圧縮されたコンテンツを強制的にフィードすることを処理する必要があります。HTTP 要求/応答は対話であり、要求のほとんどのヘッダーは対話であることを理解することが重要です。リクエスト_. ほとんどの場合、相手側のサーバーは特定のヘッダーを尊重する義務はなく、意味のある有効な応答を返す限り、相手側のクライアントは返されたものを理解するために最善を尽くす必要があります. これには、サーバーが gzip を使用したと応答した場合に gzip を有効にすることが含まれます。

ただし、ターゲットがマシンの消費である場合は、少し注意してください。トピックはほとんどすべての言語の複数のライブラリで死ぬまで行われているにもかかわらず、人々は時々独自の HTTP/SMTP/etc パーサーを作成することは賢明な考えだと考えています。すべてのライブラリは gzip を問題なくサポートする必要がありますが、手作業で作成されたパーサーは通常サポートしません。

于 2012-07-26T13:38:59.290 に答える