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クライアントライブラリは、実用性に反するものです。

RFC 2616の著者の1人であるロイT.フィールディングの引用：

一貫性のない方法でコンテンツエンコーディングをオンザフライで変更する（「決して」でも「常に」でもない）と、そのコンテンツ（たとえば、PUTまたは条件付きGET）に関するその後の要求が正しく処理されなくなります。オンザフライのコンテンツエンコーディングは愚かな考えであり、リソースを変更せずにオンザフライエンコーディングを行う適切な方法として、なぜHTTPにTransfer-Encodingを追加したのか。

ソース：https : //issues.apache.org/bugzilla/show_bug.cgi?id=39727#c31

つまり、オンザフライの Content-Encodingを行わず、代わりにTransfer-Encodingを使用してください！

編集：つまり、Content-Encodingのみを理解するクライアントにgzip圧縮されたコンテンツを提供する場合を除きます。残念ながら、それらはほとんどのようです。ただし、仕様のレルムを離れると、 Fieldingによって言及された問題や他の問題（たとえば、キャッシュプロキシが関係する場合）に遭遇する可能性があることに注意してください。

正しいクライアントに送信するために使用方法は、RFC 2616で定義され、実際に野生で実装されるAccept-Encodingリクエストヘッダを（クライアントが複数のエンコーディングを指定することができます）。次に、サーバーは、クライアントのサポートされているエンコーディング（ファイルデータがそのエンコーディングにまだ格納されていない場合）に従って応答をエンコードし、Content-Encodingどのエンコーディングが使用されているかを応答ヘッダーで示します。次に、クライアントは、に基づいて、ソケットのからデータを読み取ることができるTransfer-Encoding（すなわち、chunked）、その後に基づいて、それをデコードContent-Encoding（すなわち：gzip）。

そのため、あなたのケースでは、クライアントがAccept-Encoding: gzipリクエストヘッダーを送信し、サーバーが（まだでない場合）圧縮してContent-Encoding: gzip、オプションでTransfer-Encoding: chunkedレスポンスヘッダーを送信することを決定します。

そして、はい、Transfer-Encodingヘッダーはリクエストで使用できますが、HTTP 1.1の場合のみで、クライアントとサーバーの両方の実装chunkedが両方向のエンコーディングをサポートする必要があります。

ETag実際に送信されているデータではなく、サーバー上のリソースデータを一意に識別します。特定のURLリソースのETag値が変更された場合は、そのリソースのサーバー側データが変更されたことを意味します。