範囲要求

範囲要求 (HTTP)

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

仕様書

プロトコル

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

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

処理モデル

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

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

範囲要求への応答

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

  1. [41] 条件付き要求なら、条件付き要求の処理の規定に従い条件を評価します。 それによって応答が決まるなら、ここで終わります。
  2. [45] Range: ヘッダーに対応しないなら、 ここで終わり通常の方法で処理します >>14
  3. [43] Range: ヘッダーがなければ、 範囲要求ではないので、ここで終わり通常の方法で処理します。
  4. [44] 要求メソッドGET 以外なら、 Range: ヘッダーは無視します >>14。 ここで終わり通常の方法で処理します。
  5. [46] Range: ヘッダー範囲単位が対応しないものなら、
    1. [47] 起源鯖は、 Range: ヘッダーを無視します >>14
    2. [48] は、 Range: ヘッダーを捨てても構いません >>14
    3. [49] いずれにせよ、ここで終わり通常の方法で処理します。
  6. [53] Range: ヘッダーの値を範囲単位ごとの構文に従い解釈します。
  7. [54] 3つ以上の重複する範囲を含む Range: ヘッダーや、多数の昇順でない小さな範囲を指定した Range: ヘッダーを無視したり、拒絶したりして構いません >>14
    1. [56] 拒絶する場合は、 416 応答を返してここで終わります。
    2. [57] 無視する場合は、ここで終わり通常の方法で処理します。
  8. [60] 指定された範囲が非妥当満足不能なら、 416 応答を返してここで終わります >>14
  9. [59] 指定された範囲が妥当満足可能なら、 満足可能範囲に対応する1つ以上の部分表現を含む payload をもった 206 応答を送信します >>14
    1. [71] 複数の範囲が指定されていた場合に、範囲の指定の順序に関わらず、 重なり合う範囲をまとめたり、 multipart によるオーバーヘッドより隙間が小さいときにまとめたりしても構いません。 >>61
    2. [75] multipart/byteranges を使うか判断します。
      1. [76] Range: ヘッダーで指定された範囲が1つの時は、 使用しません >>61
      2. [77] >>71 の場合は、どちらでも構いません >>61
      3. [78] それ以外の場合は、使用します >>61
    3. [63] multipart/byteranges を使用する時は、
      1. [66] 各範囲を本体部分とする multipart/byterangespayload に含めます >>61
        1. [68] 範囲を指定した Content-Range: ヘッダー本体部分に含めます >>61
        2. [70] 選択された表現200 応答だった場合の応答Content-Type: ヘッダーと同じ値の Content-Type: ヘッダー本体部分に含めるべきです >>61
        3. [69] 範囲のデータを本体部分実体本体に含めます。
    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] 206416応答ヘッダーについては、 それぞれの項も参照してください。

部分応答の結合

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

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

  1. [13] 蓄積されている応答と新しい応答強い検証子が一致するもの (200 応答206 応答) を集めます。
  2. [10] 集めた応答のいずれかが 200 応答なら、
    1. [20] 最新の 200 応答の各ヘッダーを結合した応答ヘッダーとします。 >>51
    2. [82] 警告符号1xxWarning: ヘッダーがあれば、削除します。 >>81
  3. [21] そうでない場合 (いずれも 206 応答の場合)、
    1. [22] 蓄積されている最新の応答の各ヘッダーを結合した応答ヘッダーとします。 >>51
    2. [23] 新しい応答ヘッダーで結合した応答の各ヘッダーで結合した応答ヘッダーを置き換えます。ただし Content-Range: ヘッダーは除きます。 >>51, >>81
    3. [83] 警告符号1xxWarning: ヘッダーがあれば、削除します。 >>81
  4. [39] 集めた応答から元のデータの復元を試みます。
  5. [15] データの全体が復元できた場合、
    1. [9] 結合した応答状態符号200 とします。 >>5
    2. [12] 結合した応答Content-Length: ヘッダーは得られたデータの長さとします。 >>5
    3. [38] 結合した応答Transfer-Type: ヘッダーは適切に設定します。
    4. [27] 結合した応答Transfer-Encoding: ヘッダーは削除します。
    5. [16] 結合した応答メッセージ本体は得られたデータとします。
  6. [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: ヘッダーは削除します。

[90] 304 の場合の処理モデル (応答ヘッダーの結合方法) と似ています。 226 でも同様の方法が使われます。

実現値操作 range

[87] 実現値操作 range は、 結果が範囲選択の結果としての部分内容であることを表します >>86

[92] 範囲選択とそれ以外の恒等でない実現値操作が適用された時は、 IM: にその適用順序を明記しなければなりません >>91

[93] 実現値操作として range のみが適用された時は、 IM: ヘッダーを省略するべきです。 通常は 226 ではなく 206 を使います。 >>91

[94] IM:range が含まれる時は、 Content-Range: または Content-Type: multipart/byteranges が含まれなければなりません >>91

[95] A-IM:range は1回しか指定できないと思われますが、明記されていません。

[96] 範囲要求A-IM: が含まれるとき range を指定しなければならないとは明記されていません。

[97] キャッシュにおける処理については、226 を参照。

[99] multipart/byteranges に関わる処理 >>98multipart/byteranges を参照。

メモ

[6] http - Paging in a Rest Collection - Stack Overflow ( ( 版)) <http://stackoverflow.com/questions/924472/paging-in-a-rest-collection>

[100] draft-combs-http-indeterminate-range-00 - HTTP/1.1: Range Responses of Indeterminate Length ( 版) <http://tools.ietf.org/html/draft-combs-http-indeterminate-range-00>

[101] draft-combs-http-indeterminate-range-01 - HTTP/1.1: Range Responses of Indeterminate Length ( 版) <https://tools.ietf.org/html/draft-combs-http-indeterminate-range-01>

[102] IRC logs: freenode / #whatwg / 20150731 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20150731>

[103] apacheはContent-LengthレスポンスヘッダがないとRangeリクエストが有効にならない - うまいぼうぶろぐ () <http://hogem.hatenablog.com/entry/20100724/1280074122>

[104] Rewrite HTTP cache integration (mnot著, ) <https://github.com/whatwg/fetch/commit/cbca2c2f3a37084e336e14348de683f8ffa0fed9>

[105] Specify identity encoding for range requests (jakearchibald著, ) <https://github.com/whatwg/fetch/commit/2f3d04d3713f6cd0f89d491217175b55911927be>

[106] Some servers seem to expect 'Accept-Encoding : identity' to serve Range requests · Issue #747 · whatwg/fetch () <https://github.com/whatwg/fetch/issues/747>