0

Rangeヘッダーはコンテンツ ネゴシエーションでどのように機能しますか? 説明させてください。まず最初に、次のことに同意しましょう。HTTP はステートレス プロトコルです。

HTTP サーバーが単一のリソースの複数の表現を送信できる場合、コンテンツ ネゴシエーションを使用して、どの表現を送信するかを決定します。クライアントが好み (つまり、英語と GIF) を示し、サーバーがそれに従うか、または -- 以下のシナリオでできません -- サーバーはヒューリスティックな評価を通じて、どの表現をクライアントに送信するかを選択します。

これまでのところは順調ですがRange、ミックスに投入するとどうなりますか?

次のシナリオを想像してください。

ジョンはパリの空港にいて、ブラウザが HTTP リクエストを送信します。何らかの理由で、彼のブラウザーは、コンテンツの種類、言語、および圧縮の設定を示しません。

GET /uri HTTP/1.1
Host: example.com

通過するものがほとんどないため、サーバーはいくつかのヒューリスティックを使用して、URI のフランス語表現を送信することを決定します (IP はフランスからのものとして認識されます)。

200 Okay
Accept-Ranges: bytes
Content: text/html
Content-Language: fr
....data...

転送の途中で、ジョンはフライトに間に合うようにダウンロードを停止します。John はニューヨークに到着すると、ダウンロードを再開します。

 GET /uri HTTP/1.1
 Host: example.com
 Range: 2000-3000

繰り返しになりますが、クライアントの好みに関する情報がほとんどないため、サーバーは今度は URI の英語表現を送信することを決定します (IP はニューヨークからのものとして認識されます)。

この時点で、ファイルの一部はフランス語で残りの部分は英語であるため、ファイルは破損しています。

推測：

  • クライアントは、最初の応答のコンテンツ タイプと言語を記憶して、2 番目の要求 ( の下) でその情報をサーバーに送り返すことができますAccept: text/html Accept-Language: fr。ただし、 RFC2616もRFC7233もこれに関して何も述べていないため (推奨事項でさえありません)、この動作を行う HTTP クライアントはまれであると思いますが、まだテストしていません。

ノート：

  • 上記のシナリオでは、クライアントにプリファレンスを送信させ、サーバーを準拠させることができず、他のヒューリスティックにフォールバックすることが簡単にできます。問題は解決しません。
  • 別の例として、この問題は別の SO の質問にも存在します: Sample http range request session

TL;DR

GET /uri HTTP/1.1
Host: example.com
Accept: text/html; q=1.0, text/plain; q=0.8, */*; q=0.1
Accept-Language: en; q=1.0, */*; q=0.1
Range: 100-200

上記では、範囲は要求されたリソースのどの表現に適用されますか?!

4

1 に答える 1

0

簡単な答え: If-Match: etag リクエスト ヘッダー フィールドなしで Range リクエストを使用しないでください。

于 2015-02-02T18:50:43.157 に答える