106

やるかどうかというと、現在の状況はどうですか？

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 でほとんど行われていることを行う正しい方法です。
  • ETagContent-Encoding は、そのセマンティックな意味合いのために、いくつかの問題を抱えています (サーバーが応答を透過的に圧縮する場合、サーバーは何をすべきでしょうか?)
  • その理由はニワトリと卵です: サーバーがサポートしていないため、ブラウザーがサポートしていないため、ブラウザーがサポートしていません。

したがって、正しい方法は a になると想定していますTransfer-Encoding: gzip(または、さらに体をチャンクすると、 になり Transfer-Encoding: gzip, chunkedます)。Varyそして、それはトランスポートレベルのものであるため、その場合、またはETag他のヘッダーに触れる理由はありません。

今のところ、私は の「ホップバイホップ」性についてはあまり気にしていません。これはTransfer-Encoding、プロキシが圧縮解除され、圧縮解除された状態でクライアントに転送される可能性があるためです。ただし、元のリクエストに適切なAccept-Encodingヘッダーが含まれている場合、プロキシはそれをそのまま（圧縮して）転送することもできます。これは、私が知っているすべてのブラウザーの場合です。

ところで、この問題は少なくとも 10 年前のものです。たとえば https://bugzilla.mozilla.org/show_bug.cgi?id=68517を参照してください。

これに関する説明をいただければ幸いです。標準に準拠していると見なされるものと、実用的であると見なされるものの両方の観点から。たとえば、透過的な「Content-Encoding」のみをサポートする HTTP クライアント ライブラリは、実用性に反する議論になります。

4

2 に答える 2

36

RFC 2616 の作成者の 1 人であるRoy T. Fieldingを引用します。

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

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

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

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

于 2012-07-26T07:19:45.120 に答える
34

RFC 2616 で定義され、実際に実装されている正しい使用法は、クライアントが要求ヘッダーを送信することです(Accept-Encodingクライアントは複数のエンコーディングを指定する場合があります)。その後、サーバーは、クライアントがサポートするエンコーディング (ファイル データがまだそのエンコーディングで保存されていない場合) に従って応答をエンコードし、Content-Encoding使用されているエンコーディングを応答ヘッダーで示します。Transfer-Encodingクライアントは、 (ie, )に基づいてソケットからデータを読み取り、 (ie: )chunkedに基づいてデコードできます。Content-Encodinggzip

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

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

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

于 2013-05-07T02:25:28.977 に答える