RFC 2068 14.36.1・RFC 2616 14.35.1 Byte Ranges#✎

Since all HTTP entities are represented in HTTP messages as sequences of bytes, the concept of a byte range is meaningful for any HTTP entity. (However, not all clients and servers need to support byte-range operations.)

HTTP 実体は HTTP メッセージ中ではすべてバイト列として表現されますから、 任意の HTTP 実体に対してバイト範囲という概念が意味を持ちます。 (しかし、すべてのクライアントと鯖がバイト範囲操作に対応する必要はありません。)

Byte range specifications in HTTP apply to the sequence of bytes in the entity-body (not necessarily the same as the message-body).

HTTP でのバイト範囲指定は、 entity-body (必ずしも message-body と同じではない。) のバイト列に適用します。

A byte range operation may MAY specify a single range of bytes, or a set of ranges within a single entity.

バイト範囲操作は単一の範囲か、または単一の実体内の範囲の集合を指定して構いません。

• ranges-specifier = byte-ranges-specifier
• byte-ranges-specifier = bytes-unit "=" byte-range-set
• byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
• byte-range-spec = first-byte-pos "-" [last-byte-pos]
• first-byte-pos = 1*DIGIT
• last-byte-pos = 1*DIGIT

The first-byte-pos value in a byte-range-spec gives the byte-offset of the first byte in a range. The last-byte-pos value gives the byte-offset of the last byte in the range; that is, the byte positions specified are inclusive. Byte offsets start at zero.

byte-range-spec の first-byte-pos 値は、範囲中の最初のバイトのバイト offset を与えます。 last-byte-pos 値は範囲中の最後のバイトのバイト offset を与えます。つまり、指定されたバイト位置は範囲に含まれます。 バイト offset は零から始めます。

If the last-byte-pos value is present, it must MUST be greater than or equal to the first-byte-pos in that byte-range-spec, or the byte-range-spec is syntactically invalid. The recipient of a byte-range-set that includes one or more syntactically an invalid byte-range-spec values MUST must ignore it the header field that includes that byte-range-set.

last-byte-pos 値が示されるときは、その byte-range-spec の first-byte-pos 以上でなければなりません。 そうでなければ構文的に不当です。一つ以上の構文的に不正な byte-range-spec 値を含む byte-range-set の受信者は、その byte-range-set を含む頭欄を無視しなければなりません。

If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the entity-body, last-byte-pos is taken to be equal to one less than the current length of the entity-body in bytes.

last-byte-pos が欠けている場合、あるいは entity-body の現在の長さ以上のときは、 last-byte-pos は現在の entity-body のバイト長より一小さいものと取ります。

By its choice of last-byte-pos, a client can limit the number of bytes retrieved without knowing the size of the entity.

last-byte-pos を選ぶことにより、クライアントは実体の寸法を知らなくても取り出すバイト数を制限できます。

• suffix-byte-range-spec = "-" suffix-length
• suffix-length = 1*DIGIT

A suffix-byte-range-spec is used to specify the suffix of the entity-body, of a length given by the suffix-length value. (That is, this form specifies the last N bytes of an entity-body.) If the entity is shorter than the specified suffix-length, the entire entity-body is used.

suffix-byte-range-spec は、 entity-body の接尾部を suffix-length 値で与えた長さ分指定するのに使います。 (つまり、この書式は entity-body の最後の N バイトを指定します。) 実体が指定された suffix-length よりも短い場合には、 entity-body 全体を使います。

Examples of byte-ranges-specifier values (assuming an entity-body of length 10000):

byte-ranges-specifier 値の例 (長さ 10000 の entity-body を仮定):

• o - The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499
• o - The second 500 bytes (byte offsets 500-999, inclusive): bytes=500-999
• o - The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=-500
• o - Or bytes=9500-
• o - The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1
• o - Several legal but not canonical specifications of the second 500 bytes (byte offsets 500-999, inclusive):
  • bytes=500-600,601-999
  • bytes=500-700,601-999

RFC 2068 14.36.2・RFC 2616 14.35.2 Range Retrieval Requests#✎

HTTP retrieval requests using conditional or unconditional GET methods may MAY request one or more sub-ranges of the entity, instead of the entire entity, using the Range request header, which applies to the entity returned as the result of the request:

条件付または条件付でない GET 方式の HTTP 取り出し要求は、 要求の結果として返される実体に適用されるものである Range 要求頭を使って、 実体全体ではなく、実体の一つ以上の部分範囲を要求して構いません。

• Range = "Range" ":" ranges-specifier

A server MAY ignore the Range header. However, HTTP/1.1 origin servers and intermediate caches SHOULD ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval of large entities.

鯖は、 Range 頭を無視しても構いません。 しかし、 HTTP/1.1 起点鯖と中間キャッシュは、 可能な時にはバイト範囲に対応するべきです。なぜなら、 Range は部分的に失敗した転送から効率よく回復することや大きな実体の部分を効率的に取り出すことを支援するからです。

If the server supports the Range header and the specified range or ranges are appropriate for the entity:

• o - The presence of a Range header in an unconditional GET modifies what is returned if the GET is otherwise successful. In other words, the response carries a status code of 206 (Partial Content) instead of 200 (OK).
• o - The presence of a Range header in a conditional GET (a request using one or both of If-Modified-Since and If-None-Match, or one or both of If-Unmodified-Since and If-Match) modifies what is returned if the GET is otherwise successful and the condition is true. It does not affect the 304 (Not Modified) response returned if the conditional is false.

鯖が Range 頭に対応し、指定された範囲(群)がその実体について適当であるなら、

• 条件付きでない GET での Range 頭の存在は、 GET が本来成功であるなら返されるものを修飾します。 言い換えれば、応答は状態符号 200 (了解) の代わりに 206 (部分内容) となります。
• 条件付き GET (If-Modified-Since と If-None-Match の一方又は両方、もしくは If-Unmodified-Since と If-Match の一方又は両方を使った要求) での Range 頭の存在は、 GET が本来成功であって、条件が真であるなら返されるものを修飾します。 条件が偽であるときに返される 304 (未修正) 応答には影響しません。

In some cases, it may might be more appropriate to use the If-Range header (see section 14.27) in addition to the Range header.

場合によっては、 Range 頭に加えて If-Range 頭もあわせて使ったほうがより適切かもしれません。

If a proxy that supports ranges receives a Range request, forwards the request to an inbound server, and receives an entire entity in reply, it SHOULD only return the requested range to its client. It SHOULD store the entire received response in its cache, if that is consistent with its cache allocation policies.

範囲に対応した串が Range 要求を受信し、 上りサーバーに要求を転送し、返事の実体全体を受信したら、 クライアントには要求された範囲だけを返すべきです。 受信した応答がキャッシュ割当て方針に沿っているなら、 受信した応答全体をキャッシュに蓄積するべきです。