byte-ranges-specifier

範囲単位 bytes (HTTP)

[4] bytes は、バイトの範囲を表す範囲単位です。

目次

  1. 仕様書
  2. 意味
  3. Range: ヘッダーにおける範囲の指定
  4. Content-Range: ヘッダーでの範囲の指定
    1. バイト範囲の構文
    2. 長さの構文
    3. */*
  5. 歴史
  6. 実装
  7. 関連
  8. メモ

仕様書#

意味#

[5] 範囲単位 bytes は、データのオクテット列の部分範囲を表します >>3

Range: ヘッダーにおける範囲の指定#

[6] Range: ヘッダーにおけるバイト範囲の値は、 範囲単位の後に = と範囲のリスト (#) を記述して指定します >>3

bytes=範囲OWS,OWS範囲

[7] 範囲は、先頭の位置と末尾の位置で指定するか、先頭の位置のみで指定するか、 長さのみで指定するかのいずれかの方法で記述します >>3

位置-位置位置--長さ

[8] 位置や長さは1文字以上のASCII数字の列で十進数として表します >>3

[22] 受信者桁溢れに注意しなければなりません >>3
ASCII数字

[9] 位置の指定は、バイト列の先頭を 0 とした時の位置 (offset) として解釈します。指定された先頭または最後のバイトも、範囲に含まれます。 >>3

[13] 最後のバイトが指定されていない場合や、実際のデータの最後のバイトより後を指している時は、 残りすべてを表します。 >>3

[14] クライアントが実際の長さを知らなくても取得する最大のデータ長を指定したい時に、 適当に大きな値を指定することができます。

[12] 先頭と最後が明記されていて、先頭より最後のバイトの方が小さな値の範囲は、 非妥当です >>3

[23] 先頭がデータの長さより大きな値であっても非妥当とはならないようですが、 データのどの部分も表しません。

[10] bytes=0-499 は、先頭500バイトを表します >>3

[11] bytes=500-999 は、その後に続く500バイトを表します >>3

[15] 長さによる範囲の指定は、データの最後から指定された数のバイトを表します。 実際のデータの長さより大きい時は、全体を表します。 >>3

[20] 意味はありませんが、 bytes=-0 も禁止されていないようです。

[16] 長さが10000のデータに対して bytes=-500bytes=9500-9999bytes=9500- と同じ意味になります >>3

[17] 範囲のリストは、それぞれの範囲によって表されるバイト列のリストを表しています。 各範囲は重複していることもあります。

[18] bytes=0-0,-1 は先頭バイトと末尾バイトを表しています >>3

[19] bytes=500-600,601-999bytes=500-700,601-999 は、 bytes=500-999 と同じ範囲を表していますが冗長です >>3

[21] 範囲のリストにおいて、範囲の先頭の位置がデータの長さより小さな値か、 長さが0でないものが最低1つでもあれば、これは満足可能 (satisfiable) です。 そうでなければ満足不能 (unsatisfiable) です。 >>3

[25] 妥当性や満足可能性は、Range: ヘッダーの処理で使われます。

[26] 範囲のリストにおける範囲の順序や重複、個数などについては、 Range: ヘッダーの項を参照してください。

Content-Range: ヘッダーでの範囲の指定#

[28] Content-Range: ヘッダーにおける範囲の値は、 範囲単位SP の後に、範囲を1つ指定したものです。 >>27

bytesSP範囲

[29] 範囲は、先頭の位置、-、最後の位置、/、全体の長さの順に指定します。 ただし、 / の前後どちらか一方は * とすることができます。 >>27

位置-位置/長さ**/長さ

[30] 位置や長さは、1文字以上のASCII数字によって表します >>27。 これは十進数として解釈されます。

ASCII数字

バイト範囲の構文#

[36] 206 応答では、先頭と最後の位置を指定する構文を使わなければなりません。

[33] 先頭の位置と最後の位置は、全体の先頭を 0 とした時のオフセット値で、 それぞれの位置のバイトをも含みます。

[34] 先頭の位置より最後の位置の方が小さい場合、非妥当です >>27

[35] Content-Range:非妥当の場合、それが表す範囲は無視しないといけません (Content-Range: 参照)。

[32] 全体の長さのかわりの * は、生成の時点で長さが分からないことを示します >>27

[31] 送信者は、分からない場合や決定しがたい場合を除き、 全体の長さを指定するべきです>>27

[39] 次の例 >>27 は、1234バイトのデータのうち、43個目のバイト以降が含まれることを表しています。

Content-Range: bytes 42-1233/1234

[40] 次の例 >>27 は、長さ不明のデータのうち、43個目のバイトから1234個目のバイトまでが含まれることを表しています。

Content-Range: bytes 42-1233/*

長さの構文#

[37] は、バイト範囲要求に対して 416 応答を返す場合、 前半が * の構文を使った Content-Range: ヘッダーを送信するべきです >>27

[38] こちらの構文では、長さ不明にはできません。長さ不明の時はヘッダー自体を送るべきではないと思われます。

[41] 次の例 >>27 は、適用対象のデータの長さが1234バイトであることを表しています。

Content-Range: bytes */1234

*/*#

[44] RFC 723x は認めていませんが、 Google BigQueryContent-Range: bytes */* という指定を認めています >>45

歴史#

[2] RFC 2068・2616 (HTTP/1.1) 3.12 Range Units

HTTP/1.1 allows a client to request that only part (a range of) the response entity be included within the response. HTTP/1.1 uses range units in the Range (section 14.36 14.35) and Content-Range (section 14.17 14.16) header fields. An entity may can be broken down into subranges according to various structural units.

HTTP/1.1 では、応答実体の部分 (範囲) のみを応答中に含めるようにクライアント要求することを認めます。 HTTP/1.1 は、範囲単位を Range 頭欄と Content-Range 頭欄で使います。 実体は種々の構造単位に基づいて小範囲に分割できます。

  • range-unit = bytes-unit | other-range-unit
  • bytes-unit = "bytes"
  • other-range-unit = token

The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations may MAY ignore ranges specified using other units.

HTTP/1.1 で定義する範囲単位は bytes だけです。 HTTP/1.1 実装は他の単位を使って指定されている範囲を無視しても構いません

HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges.

HTTP/1.1 は範囲の知識に依存しない応用の実装を認めるように設計されています。

実装#

[42] 汎用の WebブラウザーHTTP鯖bytes による範囲要求に (少なくても静的ページに関しては) 対応しているのが普通です。

[43] ダウンロードに特化した利用者エージェントbytes 単位の範囲要求によりダウンロードの途中からの継続に対応しているのが普通です。

関連#

[24] は、 Accept-Ranges: bytes によってバイト範囲に対応していることを明示できます。

メモ#

[1] HTTP では他の単位が使われてるのって見たことないですね。

[46] draft-luotonen-http-url-byterange-01 - Byte Ranges With HTTP URLs ( 版) <https://tools.ietf.org/html/draft-luotonen-http-url-byterange-01>

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