Transfer-Encoding：gzipとContent-Encoding：gzip
それをするかどうかということになると、現在の状況はどうですか Transfer-Encoding: gzip または Content-Encoding: gzip たとえば、帯域幅が制限されているクライアントに、圧縮された応答を受け入れる意志があることを通知することを許可し、サーバーが最終的に圧縮するかどうかを決定する場合。 後者は、たとえば、Apacheのmod_deflateとIISが圧縮を処理する場合に行うことです。圧縮するコンテンツのサイズに応じて、追加の処理が行われますTransfer-Encoding: chunked。 またVary: Accept-Encoding、既に問題のヒントとなっているも含まれます。Content-Encodingエンティティの一部であるように見えるため、エンティティの変更に応じてContent-Encoding金額を変更します。つまり、Accept-Encodingヘッダーが異なるということは、たとえば、キャッシュがそれ以外の場合は同一のエンティティのキャッシュバージョンを使用できないことを意味します。 私が見逃した明確な答えはありますか（そして、それはいくつかのApacheニュースグループの長いスレッドのメッセージの中に埋め込まれていません）？ 私の現在の印象は： Transfer-Encodingは、実際には、既存のサーバーとクライアントの実装によってContent-Encodingで主に行われることを実行する正しい方法です Content-Encodingは、その意味上の影響のため、いくつかの問題を抱えています（サーバーがETag応答を透過的に圧縮する場合、サーバーは何をすべきですか？） その理由は、ニワトリではありません。ブラウザがサポートしていないためサーバーがサポートしていないため、ブラウザはそれをサポートしていません。 私は正しい方法を想定していますので、だろうTransfer-Encoding: gzip（Iさらにチャンク体、それがあれば、またはなります Transfer-Encoding: gzip, chunked）。タッチする理由VaryやETag、それはトランスポートレベルのことだとして、その場合には、他のヘッダをか。 今のところ、の「ホップバイホップ」性についてはあまり気にしません。Transfer-Encodingプロキシは圧縮解除されて非圧縮でクライアントに転送される可能性があるため、他の人が何よりもまず心配しているようです。ただし、元のリクエストに適切なAccept-Encodingヘッダーが含まれている場合、プロキシはそのまま（圧縮されて）転送する可能性があります。これは、私が知っているすべてのブラウザの場合、ヘッダーが指定されているためです。 ところで、この問題は少なくとも10年前のものです。例：https : //bugzilla.mozilla.org/show_bug.cgi?id=68517を参照して ください。 これについての明確化は高く評価されます。標準に準拠していると見なされるものと、実用的であると見なされるものの両方に関して。たとえば、透過的な「Content-Encoding」のみをサポートするHTTPクライアントライブラリは、実用性に反するものです。