範囲要求 (HTTP)

[2] Range: が指定された要求を、範囲要求 (range request) といいます。範囲要求を使うと資源の一部分のみをバイト単位で指定して受信できます。

仕様書

[1] RFC 7233 - Hypertext Transfer Protocol (HTTP/1.1): Range Requests (2014-09-11 09:57:55 +09:00 版) <https://tools.ietf.org/html/rfc7233>
[81] RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching (2014-09-11 10:19:59 +09:00 版) <https://tools.ietf.org/html/rfc7234#section-3.3>
[86] RFC 3229 - Delta encoding in HTTP (2014-10-26 21:15:25 +09:00 版) <http://tools.ietf.org/html/rfc3229#section-10.1>
[91] RFC 3229 - Delta encoding in HTTP (2014-10-26 21:15:25 +09:00 版) <http://tools.ietf.org/html/rfc3229#section-10.5.2>
[98] RFC 3229 - Delta encoding in HTTP (2014-10-26 21:15:25 +09:00 版) <http://tools.ietf.org/html/rfc3229#section-10.10>

プロトコル

[4] 範囲要求は次のプロトコル要素により構成されます。

[85] 範囲要求は GET 要求にのみ適用されます。他の要求メソッドでは使えません。

処理モデル

[3] 範囲要求への対応は必須ではありません >>1。範囲要求を受信した時、これに対応していない場合は、通常の GET 要求として処理して構いません >>1。

[84] HTTP鯖の処理全体における位置付けは HTTP鯖の項を、キャッシュにおける取り扱い全体はキャッシュ項目の項を、実現値操作との関係は実現値操作の項を参照してください。

範囲要求への応答

[42] 鯖は、範囲要求を次のように処理しなければなりません。

[41] 条件付き要求なら、条件付き要求の処理の規定に従い条件を評価します。それによって応答が決まるなら、ここで終わります。
[45] 鯖が Range: ヘッダーに対応しないなら、ここで終わり通常の方法で処理します >>14。
[43] Range: ヘッダーがなければ、範囲要求ではないので、ここで終わり通常の方法で処理します。
[44] 要求メソッドが GET 以外なら、 Range: ヘッダーは無視します >>14。ここで終わり通常の方法で処理します。
[46] Range: ヘッダーの範囲単位が対応しないものなら、
1. [47] 起源鯖は、 Range: ヘッダーを無視します >>14。
2. [48] 串は、 Range: ヘッダーを捨てても構いません >>14。
3. [49] いずれにせよ、ここで終わり通常の方法で処理します。
[53] Range: ヘッダーの値を範囲単位ごとの構文に従い解釈します。
[54] 3つ以上の重複する範囲を含む Range: ヘッダーや、多数の昇順でない小さな範囲を指定した Range: ヘッダーを無視したり、拒絶したりして構いません >>14。
- [55] これらを送信したクライアントは壊れているのかもしれませんし、 DoS攻撃かもしれません。 >>14, >>40
1. [56] 拒絶する場合は、 416 応答を返してここで終わります。
2. [57] 無視する場合は、ここで終わり通常の方法で処理します。
[60] 指定された範囲が非妥当か満足不能なら、 416 応答を返してここで終わります >>14。
[59] 指定された範囲が妥当で満足可能なら、満足可能な範囲に対応する1つ以上の部分表現を含む payload をもった 206 応答を送信します >>14。
1. [71] 複数の範囲が指定されていた場合に、範囲の指定の順序に関わらず、重なり合う範囲をまとめたり、 multipart によるオーバーヘッドより隙間が小さいときにまとめたりしても構いません。 >>61
  - [72] 一般的には multipart/byteranges のオーバーヘッドは 80バイト程度です。 >>61
  - [73] >>54 の DoS攻撃への対策にもなります。
2. [75] multipart/byteranges を使うか判断します。
  1. [76] Range: ヘッダーで指定された範囲が1つの時は、使用しません >>61。
  2. [77] >>71 の場合は、どちらでも構いません >>61。
  3. [78] それ以外の場合は、使用します >>61。
3. [63] multipart/byteranges を使用する時は、
  1. [66] 各範囲を本体部分とする multipart/byteranges を payload に含めます >>61。
    1. [68] 範囲を指定した Content-Range: ヘッダーを本体部分に含めます >>61。
    2. [70] 選択された表現が 200 応答だった場合の応答の Content-Type: ヘッダーと同じ値の Content-Type: ヘッダーを本体部分に含めるべきです >>61。
    3. [69] 範囲のデータを本体部分の実体本体に含めます。
  - [74] 満足不能な範囲や他の範囲とまとめた場合 (>>71) を除き、 Range: に指定された順序で本体部分を並べるべきです >>61。
  - [67] 応答のヘッダーとしては Content-Range: を生成してはなりません >>61。
4. [62] それ以外の場合、
  1. [64] 範囲を指定した Content-Range: ヘッダーを生成します >>61。
  2. [65] 範囲のデータを payload に含めます >>61。

[51] Range: ヘッダーが複数指定された時の動作は規定されていません。

[58] Range: ヘッダーの値が構文的に正しくない場合の動作は規定されていません。

[52] 起源鯖と中間キャッシュは可能ならバイト範囲に対応するべき (ought to) です >>14。

[50] >>60 と >>59 はなぜか MUST ではなく SHOULD です >>14。 >>54 や >>45 の場合を考慮してなのかもしれませんが、説明がないのでよくわかりません。また妥当・満足可能な範囲と非妥当・満足不能な範囲が混在する時、どちらを返すべきかは不明瞭です。

[79] 206 や 416 の応答のヘッダーについては、それぞれの項も参照してください。

部分応答の結合

[7] クライアントは、 HTTP接続が閉じられるのが早すぎた場合 (不完全な 200 応答)や、範囲要求によって応答を得た場合 (206 応答) に、同じ強い検証子を持っていればそれらを安全に組み合わせることができます >>5, >>81。

[8] 結合した応答は次のように決めます。

[13] 蓄積されている応答と新しい応答で強い検証子が一致するもの (200 応答と 206 応答) を集めます。
[10] 集めた応答のいずれかが 200 応答なら、
1. [20] 最新の 200 応答の各ヘッダーを結合した応答のヘッダーとします。 >>51
2. [82] 警告符号が 1xx の Warning: ヘッダーがあれば、削除します。 >>81
[21] そうでない場合 (いずれも 206 応答の場合)、
1. [22] 蓄積されている最新の応答の各ヘッダーを結合した応答のヘッダーとします。 >>51
2. [23] 新しい応答のヘッダーで結合した応答の各ヘッダーで結合した応答のヘッダーを置き換えます。ただし Content-Range: ヘッダーは除きます。 >>51, >>81
3. [83] 警告符号が 1xx の Warning: ヘッダーがあれば、削除します。 >>81
[39] 集めた応答から元のデータの復元を試みます。
[15] データの全体が復元できた場合、
1. [9] 結合した応答の状態符号は 200 とします。 >>5
2. [12] 結合した応答の Content-Length: ヘッダーは得られたデータの長さとします。 >>5
3. [38] 結合した応答の Transfer-Type: ヘッダーは適切に設定します。
4. [27] 結合した応答の Transfer-Encoding: ヘッダーは削除します。
5. [16] 結合した応答のメッセージ本体は得られたデータとします。
[19] 全体にはならなかった場合、
1. [18] 得られたデータが元のデータの最初の部分だった時は、次のようにして構いません。
  1. [24] 結合した応答の状態符号は 200 とします。 >>5
  2. [25] 結合した応答の Content-Length: ヘッダーは得られたデータの長さとします。 >>5
  3. [37] 結合した応答の Transfer-Type: ヘッダーは適切に設定します。
  4. [28] 結合した応答の Transfer-Encoding: ヘッダーは削除します。
  5. [26] 結合した応答のメッセージ本体は得られたデータとします。
2. [29] そうしない場合、次のようにして構いません。
  1. [17] 結合した応答の状態符号は 206 とします。 >>5
  2. [11] 結合した応答のメッセージ本体は得られたデータの各連続部分を含む multipart/byteranges 実体とします。 >>5
  3. [30] 結合した応答の Content-Type:, Content-Length: は適当に設定し、 Content-Range:, Transfer-Encoding: は削除します。
3. [31] そうしない場合、得られたデータの各連続部分について、
  1. [32] 結合した応答の複製を用意します。
  2. [33] その状態符号は 206 とします。 >>5
  3. [34] そのメッセージ本体はデータの連続部分とします。 >>5
  4. [35] その Content-Range: ヘッダーを適切に設定します。 >>5
  5. [36] その Content-Type: ヘッダーと Content-Length: ヘッダーを適切に設定し、 Transfer-Encoding: ヘッダーは削除します。