HTTP/1.1 — 範囲要請

1.1. 適合性, ~errorの取扱い

この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

適合性の判定基準, および ~errorの取扱いに関する考慮点は、 `7230-2.5$rfc にて定義される。 ◎ Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].

1.2. 構文の表記法

【 この節の他の内容は、 `~HTTP日本語訳 共通~page＠~HTTPcommon#syntax-notation$に移譲。 】

`総集的~ABNF＠~723Xabnf#abnf-7233$ にて、他の文書から取込まれた規則, および すべての`~list演算子$を標準な~ABNF表記法に展開した，総集的な文法を示す。 ◎ This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix C describes rules imported from other documents. Appendix D shows the collected grammar with all list operators expanded to standard ABNF notation.

2.1. ~byte範囲

`表現~data$は，~octet列として~payload内に転送されるので、~byte範囲は，~HTTP越しに転送し得る どの`表現$に対しても，意味のある下位構造になる。 `範囲~単位$ "`bytes@c" が、~octet列~dataの一連の部分範囲を表出するために定義される。 ◎ Since representation data is transferred in payloads as a sequence of octets, a byte range is a meaningful substructure for any representation transferable over HTTP (Section 3 of [RFC7231]). The "bytes" range unit is defined for expressing subranges of the data's octet sequence.

`bytes-unit@p
	= "`bytes$c"

~byte範囲の要請は、単独の`表現$の中の， 1 個~以上の~byte列~範囲を指定できる。 ◎ A byte-range request can specify a single range of bytes or a set of ranges within a single representation.

`byte-ranges-specifier@p
	= `bytes-unit$p "=" `byte-range-set$p
`byte-range-set@p
	= 1#( `byte-range-spec$p / `suffix-byte-range-spec$p )
`byte-range-spec@p
	= `first-byte-pos$p "-" [ `last-byte-pos$p ]
`first-byte-pos@p
	= 1*`DIGIT$P
`last-byte-pos@p
	= 1*`DIGIT$P

`byte-range-spec$p における［ `first-byte-pos$p 値, `last-byte-pos$p 値 ］は、順に，範囲の［ 最初の, 最後の ］~byte位置を，~zeroから数えた~byte数で与える。 すなわち、指定された~byte位置は範囲に含まれ， "`0^c" は先頭~byteを~~指す。 ◎ 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.

［ `last-byte-pos$p 値が在る, かつ その値が `first-byte-pos$p より小さい ］ような `byte-range-spec$p は、妥当でない。 ◎ A byte-range-spec is invalid if the last-byte-pos value is present and less than the first-byte-pos.

`~client$は、`選定される表現$の~sizeを知ることなく，要請される~byte数を制限できる。 ［ `last-byte-pos$p 値が無い, または，その値が`表現~data$の現在の長さ以上 ］の場合の`~byte範囲$は、`表現$の `first-byte-pos$p 以降の~~部分として解釈される（すなわち，~serverは、 `last-byte-pos$p の値を ( `選定された表現$の現在の長さ − 1 ) に置換する）。 ◎ A client can limit the number of bytes requested without knowing the size of the selected representation. If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the representation data, the byte range is interpreted as the remainder of the representation (i.e., the server replaces the value of last-byte-pos with a value that is one less than the current length of the selected representation).

`suffix-byte-range-spec$p を利用すれば、 `~client$は，`選定される表現$の最後の `N^var ~byteを要請できる： ◎ A client can request the last N bytes of the selected representation using a suffix-byte-range-spec.

`suffix-byte-range-spec@p
	= "-" `suffix-length$p
`suffix-length@p
	= 1*`DIGIT$P

`選定された表現$が，指定された `suffix-length$p より短い場合、`表現$~~全体が利用される。 ◎ If the selected representation is shorter than the specified suffix-length, the entire representation is used.

【† 表現の長さが~zeroであっても，定義に従う（上述の，表現の長さが `suffix-length$p より短い場合に該当する — `4391$errata ） 】

`byte-range$p 構文 における［ `first-byte-pos$p, `last-byte-pos$p, `suffix-length$p ］は、~octet数を 10 進~数で表出する。 ~payloadの長さには定義済み上限はないので、`受信者$は，［ ~decimal数字列が巨大になり得ることや, 整数~変換の桁溢れ ］を見越して，それらによる~errorを防がなければナラナイ。 ◎ In the byte-range syntax, first-byte-pos, last-byte-pos, and suffix-length are expressed as decimal number of octets. Since there is no predefined limit to the length of a payload, recipients MUST anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows.

2.2. 他の範囲~単位

`範囲~単位$は拡張-可能に意図されている。 新たな`範囲~単位$は，~IANAにて登録される~OUGHT（`5.1$secを見よ）。 ◎ Range units are intended to be extensible. New range units ought to be registered with IANA, as defined in Section 5.1.

`other-range-unit@p
	= `token$p

2.3. `Accept-Ranges^h

`Accept-Ranges$h ~headerにより、`~server$は，［ `~target資源$に対する`範囲~要請$を~supportする ］ことを指示できるようになる。 ◎ The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.

`Accept-Ranges@p
	= `acceptable-ranges$p
`acceptable-ranges@p
	= 1#`range-unit$p
	/ "`none$c"

`生成元~server$は、所与の`~target資源$に対する`~byte範囲$の要請を~supportするならば、~supportする`範囲~単位$を指示するために，次を送信してもヨイ： ◎ An origin server that supports byte-range requests for a given target resource MAY send

Accept-Ranges: bytes

`~client$は、この~headerを受信していなくても，当の資源に対し `範囲~要請$を`生成し$てもヨイ。 ◎ to indicate what range units are supported. A client MAY generate range requests without having received this header field for the resource involved. Range units are defined in Section 2.

`~target資源$に対し，いかなる`範囲~要請$も~supportしない`~server$は、 "`none@c" を送信してもヨイ： ◎ A server that does not support any kind of range request for the target resource MAY send

Accept-Ranges: none

これは、~clientに，範囲~要請を試みないように通告する。 ◎ to advise the client not to attempt a range request.

3.1. `Range^h

`GET$m 要請~上の `Range^h ~headerは、［ 選定された`表現~data$~~全体でなく，その 1 個~以上の部分範囲のみ ］の転送を要請するように，~method意味論を改変する。 ◎ The "Range" header field on a GET request modifies the method semantics to request transfer of only one or more subranges of the selected representation data, rather than the entire selected representation data.

`Range@p
	= `byte-ranges-specifier$p
	/ `other-ranges-specifier$p
`other-ranges-specifier@p
	= `other-range-unit$p "=" `other-range-set$p
`other-range-set@p
	= 1*`VCHAR$P

`~server$は、 `Range$h ~headerを無視してもヨイ。 しかしながら， `生成元~server$／媒介~cache は、アリなときは`~byte範囲$を~supportする~OUGHT — `Range$h は［ 部分的に失敗した転送の効率的な回復や, 巨大な`表現$の部分的な検索取得 ］を~supportするので。 `~server$は、［ `GET$m 以外の要請~methodに伴って受信された `Range$h ~header ］は無視しなければナラナイ。 ◎ A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations. A server MUST ignore a Range header field received with a request method other than GET.

`生成元~server$は、［ 自身が解さない`範囲~単位$を包含する `Range$h ~header ］を無視しなければナラナイ。 `~proxy$は、［ 自身が解さない`範囲~単位$を包含する `Range$h ~header ］を破棄してもヨイ。 ◎ An origin server MUST ignore a Range header field that contains a range unit it does not understand. A proxy MAY discard a Range header field that contains a range unit it does not understand.

`範囲~要請$を~supportする`~server$は、［ 【他と†】 重合する範囲が 3 個~以上ある, あるいは 昇順による順序で~listされていない 多数の小~範囲の集合 ］からなる `Range$h ~headerを無視-／却下してもヨイ — いずれも， 壊れた~client, あるいは 故意による~DoS攻撃（`6.1$sec）を指示するので。 `~client$は、処理-や転送が，同じ~dataを包摂する単独の範囲より内来的に非~効率的な，複数の範囲を要請するベキでない。 【†おそらく。 3 箇所~以上で重合する／同じ箇所に重合するものが 3 個~以上、などの解釈も考えられなくはないが。】 ◎ A server that supports range requests MAY ignore or reject a Range header field that consists of more than two overlapping ranges, or a set of many small ranges that are not listed in ascending order, since both are indications of either a broken client or a deliberate denial-of-service attack (Section 6.1). A client SHOULD NOT request multiple ranges that are inherently less efficient to process and transfer than a single range that encompasses the same data.

複数の範囲を要請する`~client$は、それらの範囲を昇順による順序で~listするベキである（概して，完全な`表現$~内にそれらが受信されることになる順序で） — 後側の部位をより早期に要請する必要が特にない限り。 例えば，［ 一連の部位についての内部~目録を伴う，巨大な`表現$ ］を処理している~UAは、後側の部位を最初に要請することも必要になり得る — 特に，`表現$が逆~順序で格納されている~pageからなっていて，~UAが一度に 1 ~pageの転送を望む場合には。 ◎ A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier. For example, a user agent processing a large representation with an internal catalog of parts might need to request later parts first, particularly if the representation consists of pages stored in reverse order and the user agent wishes to transfer one page at a time.

`Range$h ~headerが評価されるのは、`事前条件~header$を評価した後であり，［ `Range$h ~headerが無いのときの結果が `200$st 応答になる ］場合に限られる。 言い換えれば、条件付き `GET$m の結果が `304$st 応答になる場合には，範囲は無視される。 ◎ The Range header field is evaluated after evaluating the precondition header fields defined in [RFC7232], and only if the result in absence of the Range header field would be a 200 (OK) response. In other words, Range is ignored when a conditional GET would result in a 304 (Not Modified) response.

`If-Range$h ~headerを， `Range$h ~headerを適用する際の`事前条件$として利用できる。 ◎ The If-Range header field (Section 3.2) can be used as a precondition to applying the Range header field.

`~server$は、すべての`事前条件$は真に評価され, かつ `~target資源$に対する `Range$h ~headerを~supportする場合には： ◎ ↓

• 指定された範囲（たち）が妥当かつ`充足可能$ならば，［［［［ 要請された範囲のうち，`充足可能$なもの ］に対応する， 1 個~以上の部分的な表現 ］を包含する~payload ］を伴う `206$st 応答 ］を送信するベキである（`4$secを見よ）。 ◎ If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are valid and satisfiable (as defined in Section 2.1), the server SHOULD send a 206 (Partial Content) response with a payload containing one or more partial representations that correspond to the satisfiable ranges requested, as defined in Section 4.
• 他の場合， `416$st 応答を送信するベキである。 ◎ If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are invalid or unsatisfiable, the server SHOULD send a 416 (Range Not Satisfiable) response.

3.2. `If-Range^h

`~client$が，［ `表現$の`部分的$な複製を持っていて, 表現~~全体の最新の複製を望む ］ならば、 `Range$h ~headerを，（ `If-Unmodified-Since$h, `If-Match$h のいずれか, または両者を利用する）条件付き `GET$m と伴に利用できる。 しかしながら、表現が改変されたために`事前条件$が失敗した場合、~clientは，現在の表現~~全体を得するために，もう一度~要請を為さなければならなくなる。 ◎ If a client has a partial copy of a representation and wishes to have an up-to-date copy of the entire representation, it could use the Range header field with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, if the precondition fails because the representation has been modified, the client would then have to make a second request to obtain the entire current representation.

`If-Range^h ~headerにより、~clientは，次回の要請を “短絡” できるようになる。 くだけて言えば、次のような意味になる ⇒ “表現がまだ不変なら， `Range$h にて要請している部位（たち）を送信してください。 そうでなければ，表現~~全体を送信してください。” ◎ The "If-Range" header field allows a client to "short-circuit" the second request. Informally, its meaning is as follows: if the representation is unchanged, send me the part(s) that I am requesting in Range; otherwise, send me the entire representation.

`If-Range@p
	= `entity-tag$p
	/ `HTTP-date$p

`~client$は、 `Range$h ~headerを包含しない要請~内に， `If-Range$h ~headerを`生成し$てはナラナイ。 `~server$は、 `Range$h ~headerを包含しない要請~内に受信された `If-Range$h ~headerを，無視しなければナラナイ。 `生成元~server$は、 `Range$h 要請を~supportしない`~target資源$に対する要請~内に受信された `If-Range$h ~headerを，無視しなければナラナイ。 ◎ A client MUST NOT generate an If-Range header field in a request that does not contain a Range header field. A server MUST ignore an If-Range header field received in a request that does not contain a Range header field. An origin server MUST ignore an If-Range header field received in a request for a target resource that does not support Range requests.

`~server$は、［ `If-Range$h ~header内に与えられた`検証子$が，［ `~target資源$の`選定された表現$に対する現在の`検証子$ ］に合致する ］場合†には， `Range$h ~headerを要請されたように処理するベキである — 合致しない場合には， `Range$h ~headerを無視しなければナラナイ。 `検証子$が `HTTP-date$p のときも含め、この，正確な合致-による比較は、 `If-Unmodified-Since$h 条件付きを評価する際の “より早期かどうか” の比較から相違することに注意。 ◎ If the validator given in the If-Range header field matches the current validator for the selected representation of the target resource, then the server SHOULD process the Range header field as requested. If the validator does not match, the server MUST ignore the Range header field. Note that this comparison by exact match, including when the validator is an HTTP-date, differs from the "earlier than or equal to" comparison used when evaluating an If-Unmodified-Since conditional.

【† すなわち、この場合に `If-Range^h の事前条件は真であると定義される。 】

4.1. `206^st

`状態s~code$ `206$st — `部分的~応答^dfn — は、［ ~serverが，［［ 要請の `Range$h ~header内に見出された`充足可能$な範囲 ］に対応する， 1 個~以上の［ `選定された表現$の部位 ］を転送する ］ことにより，`~target資源$に対する`範囲~要請$を成功裡に履行している ］ことを指示する。 ◎ The 206 (Partial Content) status code indicates that the server is successfully fulfilling a range request for the target resource by transferring one or more parts of the selected representation that correspond to the satisfiable ranges found in the request's Range header field (Section 3.1).

【 `4358$errataによる~~修正あり（ Held for Document Update: 2015-05-07 ） — ただし、該当する状況は明確化されていない： 応答は、要請された範囲の一部のみ充足することを選択してもヨイ。 ◎ A response may chose to satisfy only part of a requested range. 】

`206^st0 応答を`生成し$ている`~server$は：

単独の部位を転送している場合

［ `選定された表現$のどの範囲が同封されたか, および 範囲を成す~payload ］を述べる `Content-Range$h ~headerを`生成し$なければナラナイ。 例えば： ◎ If a single part is being transferred, the server generating the 206 response MUST generate a Content-Range header field, describing what range of the selected representation is enclosed, and a payload consisting of the range. For example:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

... 26012 bytes of partial image data ...

複数の部位を転送している場合

"`multipart/byteranges$c" ~payload, および［ ~MIME型 "`multipart/byteranges$c" とそれに要求される境界~parameter ］を包含する `Content-Type$h ~headerを`生成し$なければナラナイ。

単独の部位による応答との混同を避けるため、この応答の~HTTP`~header節$内には， `Content-Range$h ~headerを`生成し$てはナラナイ（この~headerは、以下に述べるように，各~部位ごとに送信することになる）。

◎ If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A, and a Content-Type header field containing the multipart/byteranges media type and its required boundary parameter. To avoid confusion with single-part responses, a server MUST NOT generate a Content-Range header field in the HTTP header section of a multiple part response (this field will be sent in each part instead).

`複部位$による~payload内の各~本体~部位の~header区域の中では、その本体~部位~内に同封されている範囲に対応する， `Content-Range$h ~headerを`生成し$なければナラナイ。 `選定される表現$が，［ `200$st 応答においては `Content-Type$h ~headerを持つことになる ］ならば、その同じ `Content-Type$h ~headerを，各~本体~部位~内の~header区域~内に`生成する$ベキである。 例えば： ◎ Within the header area of each body part in the multipart payload, the server MUST generate a Content-Range header field corresponding to the range being enclosed in that body part. If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part.＼

例えば： ◎ For example:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES--

`~server$は、複数の範囲が要請されたときは、それらの範囲のうち［ 重合するもの, あるいは 複数~部位の送信による~overheadより小さな間隙で分離されるもの ］を合体してもヨイ — 対応ng `byte-range-spec$p が，受信された `Range$h ~header内に出現する順序に関わらず。 "`multipart/byteranges$c" ~payloadの各~部位~間の 代表的な~overheadは， 80 ~byte程度なので、細切れにされた多数の部位を転送するのは，［ `選定された表現$の~MIME型, および 選択された境界~parameterの長さ ］に依存して、`選定された表現$ ~~全体を転送するより非~効率的になり得る。 ◎ When multiple ranges are requested, a server MAY coalesce any of the ranges that overlap, or that are separated by a gap that is smaller than the overhead of sending multiple parts, regardless of the order in which the corresponding byte-range-spec appeared in the received Range header field. Since the typical overhead between parts of a multipart/byteranges payload is around 80 bytes, depending on the selected representation's media type and the chosen boundary parameter length, it can be less efficient to transfer many small disjoint parts than it is to transfer the entire selected representation.

`~server$は、単独の範囲に対する要請に対し，`複部位$応答を`生成し$てはナラナイ — 複数の部位を要請しなかった~clientは，`複部位$応答を~supportしないかもしれないので。 しかしながら，`~server$は、複数の範囲が要請されていて, かつ［ 唯一の範囲が`充足可能$として見出された, または 合体した後に 1 個の範囲のみ残った ］ならば、単独の本体~部位のみを伴う "`multipart/byteranges$c" ~payloadを`生成し$てもヨイ。 "`multipart/byteranges$c" 応答を処理できない`~client$は、複数の範囲を依頼する要請を`生成し$てはナラナイ。 ◎ A server MUST NOT generate a multipart response to a request for a single range, since a client that does not request multiple parts might not support multipart responses. However, a server MAY generate a multipart/byteranges payload with only a single body part if multiple ranges were requested and only one range was found to be satisfiable or only one range remained after coalescing. A client that cannot process a multipart/byteranges response MUST NOT generate a request that asks for multiple ranges.

`~server$は、`複部位$応答の~payloadを生成するときには，受信された `Range$h ~header内に出現する対応ng `byte-range-spec$p と同じ順序で，各~部位を送信するベキである — ［ `充足不可$と判断される, あるいは他の範囲に合体される ］ような範囲たちは除外した上で。 `複部位$応答を受信した`~client$は、各~本体~部位~内に在る `Content-Range$h ~headerを検分して，その本体~部位~内にどの範囲が包含されているかを決定しなければナラナイ — ~clientは、自身が要請したものと同じ［ 範囲たち／順序 ］の受信に依拠できない。 ◎ When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges. A client that receives a multipart response MUST inspect the Content-Range header field present in each body part in order to determine which range is contained in that body part; a client cannot rely on receiving the same ranges that it requested, nor the same order that it requested.

`206^st0 応答を`生成する$`~server$は、上で要求されるものに加えて，次の~headerのうち，［ 同じ要請に対する `200$st 応答~内に送信されることになるような~header ］を`生成し$なければナラナイ ⇒＃ `Date$h, `Cache-Control$h , `ETag$h, `Expires$h, `Content-Location$h, `Vary$h ◎ When a 206 response is generated, the server MUST generate the following header fields, in addition to those required above, if the field would have been sent in a 200 (OK) response to the same request: Date, Cache-Control, ETag, Expires, Content-Location, and Vary.

`206$st0 応答は、`既定で~cache可能である$ — 明示的~cache制御により指示されない限り（`7234-4.2.2$rfcを見よ）。 ◎ A 206 response is cacheable by default; i.e., unless otherwise indicated by explicit cache controls (see Section 4.2.2 of [RFC7234]).

4.2. `Content-Range^h

`Content-Range@p
	= `byte-content-range$p
	/ `other-content-range$p

`byte-content-range@p
	= `bytes-unit$p `SP$P ( `byte-range-resp$p / `unsatisfied-range$p )

`byte-range-resp@p
	= `byte-range$p "/" ( `complete-length$p / "*" )
`byte-range@p
	= `first-byte-pos$p "-" `last-byte-pos$p
`unsatisfied-range@p
	= "*/" `complete-length$p

`complete-length@p
	= 1*`DIGIT$P

`other-content-range@p
	= `other-range-unit$p `SP$P `other-range-resp$p
`other-range-resp@p
	= *`CHAR^P

【 `5620$errataに報告あり（ Reported: 2019-02-01 ）： `other-content-range$p が緩過ぎるため、妥当でない `byte-content-range$p が通ってしまう（ 例： `Content-Range: bytes 42-1233/^c ）。 】

`受信者$は、［ 自身が解さない `範囲~単位$を伴う `Content-Range$h ~header ］を包含する`206$st 応答に対しては，それを格納-済み表現と結合し直そうと試みてはナラナイ。 その種の~messageを受信した`~proxy$は、それを`下流$へ回送するベキである。 ◎ If a 206 (Partial Content) response contains a Content-Range header field with a range unit (Section 2) that the recipient does not understand, the recipient MUST NOT attempt to recombine it with a stored representation. A proxy that receives such a message SHOULD forward it downstream.

`~byte範囲$に対しては、`送信者$は，［ 抽出された範囲の表現 ］の完全な長さを指示するベキである — ［ その長さが未知, または それを決定するのが困難 ］であるのでない限り。 `byte-range-resp$p における， `complete-length$p に代わる ~asterisk （ "`*^c" ）は、~headerが生成されたときに，表現の長さが未知であったことを指示する。 ◎ For byte ranges, a sender SHOULD indicate the complete length of the representation from which the range has been extracted, unless the complete length is unknown or difficult to determine. An asterisk character ("*") in place of the complete-length indicates that the representation length was unknown when the header field was generated.

Content-Range: bytes 42-1233/1234

Content-Range: bytes 42-1233/*

［［ ( `last-byte-pos$p 値 ~LT `first-byte-pos$p 値 ), または ( `complete-length$p 値 ~LTE `last-byte-pos$p 値 ) ］であるような `byte-range-resp$p ］を包含するような `Content-Range$h ~header値は、妥当でない。 妥当でない `Content-Range$h の`受信者$は、受信された内容と格納-済みな表現を結合し直そうと試みてはナラナイ。 ◎ A Content-Range field value is invalid if it contains a byte-range-resp that has a last-byte-pos value less than its first-byte-pos value, or a complete-length value less than or equal to its last-byte-pos value. The recipient of an invalid Content-Range MUST NOT attempt to recombine the received content with a stored representation.

`~server$は、`~byte範囲$の要請に対する `416$st 応答を`生成する$ときには，［ `unsatisfied-range$p 値を伴う `Content-Range$h ~header ］を送信するベキである — 次の例のように： ◎ A server generating a 416 (Range Not Satisfiable) response to a byte-range request SHOULD send a Content-Range header field with an unsatisfied-range value, as in the following example:

Content-Range: bytes */1234

`416$st 応答~内の `complete-length$p は、`選定された表現$の現在の長さを指示する。 ◎ The complete-length in a 416 response indicates the current length of the selected representation.

`Content-Range$h ~headerは、この~headerの意味論を明示的に述べないような `状態s~code$に対しては，意味を持たない。 この仕様においては、`状態s~code$ `206$st, `416$st のみが `Content-Range$h に対する意味を述べる。 ◎ The Content-Range header field has no meaning for status codes that do not explicitly describe its semantic. For this specification, only the 206 (Partial Content) and 416 (Range Not Satisfiable) status codes describe a meaning for Content-Range.

4.3. 範囲の結合-法

応答は、［ 接続が尚早に~closeされた, または 要請が 1 個~以上の `Range$h 指定を利用した ］場合に，表現の部分範囲のみを転送し得る。 その種の転送が何度か行われたなら、~clientは，同じ表現のいくつかの範囲を受信することになるであろう。 これらの各~範囲を安全に結合できるのは、それらが揃って同じ`強い検証子$を持つ場合に限られる。 ◎ A response might transfer only a subrange of a representation if the connection closed prematurely or if the request used one or more Range specifications. After several such transfers, a client might have received several ranges of the same representation. These ranges can only be safely combined if they all have in common the same strong validator (Section 2.1 of [RFC7232]).

`~target資源$に対する何度かの `GET$m 要請に対し，複数の`不完全$な／`部分的$な応答を受信した`~client$は、［ 最も近過去に受信された応答（以下 `R^var と記す）が`強い検証子$を持つ ］ならば，［ `R^var 以外の，~cacheに格納-済みな応答のうち，同じ強い検証子を持つものたち 【のうち，いくつか？すべて？】 の集合（以下， `S^var と記す） ］とを，より大きな連続的な範囲に結合してもヨイ（結合した結果の応答を，以下 `C^var と記す）。 ◎ A client that has received multiple partial responses to GET requests on a target resource MAY combine those responses into a larger continuous range if they share the same strong validator.

`R^var は `200$st 応答である場合： ◎ If the most recent response is an incomplete 200 (OK) response, then＼

`R^var の~headerたちを `C^var に利用し、また， `S^var 内の応答たちの~headerも置換する。 ◎ the header fields of that response are used for any combined response and replace those of the matching stored responses.

`R^var は `206$st 応答であるが， `S^var 内に `200$st0 応答がある場合： ◎ If the most recent response is a 206 (Partial Content) response and at least one of the matching stored responses is a 200 (OK), then＼

`C^var の~headerたちは，それらのうち最も近過去の `200^st0 応答の~headerたちからなる。 ◎ the combined response header fields consist of the most recent 200 response's header fields.

`R^var も, `S^var 内のどの応答も， `206$st0 応答である場合： ◎ If all of the matching stored responses are 206 responses, then＼

`S^var 内の最も近過去の~headerたちを伴う応答が， `C^var の~headerたちの~sourceとして利用される — ただし，~clientは、 `Content-Range$h は別として，［ `R^var 内に供された，他の~headerたち ］を利用して，［［ `S^var 内の各 応答 ］内の対応ng~headerたちすべての~instance ］を置換しなければナラナイ。 ◎ the stored response with the most recent header fields is used as the source of header fields for the combined response, except that the client MUST use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding header fields in the stored response.

4.4. `416^st

【 `4664$errataに報告あり（ Reported: 2016-04-13 ）： 選定された資源 → `選定された表現$ 】

`~byte範囲$に対しては、現在の全範囲と重合しないことは、どの `byte-range-spec$p 値の `first-byte-pos$p も，`選定された表現$の現在の長さより大きいことを意味する。 `送信者$は、`~byte範囲$の要請に対する応答~内に，この`状態s~code$を`生成する$ときは，［ `選定された表現$の現在の長さを指定する `Content-Range$h ~header ］を`生成する$ベキである。 ◎ For byte ranges, failing to overlap the current extent means that the first-byte-pos of all of the byte-range-spec values were greater than the current length of the selected representation. When this status code is generated in response to a byte-range request, the sender SHOULD generate a Content-Range header field specifying the current length of the selected representation (Section 4.2).

HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022

注記： ~serverは `Range$h を無視してかまわないので、 多くの実装は，単純に `200$st 応答において，`選定された表現$ ~~全体で応答する。 その~~理由の一部は、ほとんどの~clientが，（たとえ効率が落ちるとしても） `200$st を受信して~taskを完了するように準備されているためであり、また，~clientには［ 完全な表現を受信するまで，妥当でない`部分的~要請$を為すのを停止しない ］ものもあるためである。 したがって，~clientは、それが最も適切になるときでも， `416$st 応答の受信には依存できない。 ◎ Note: Because servers are free to ignore Range, many implementations will simply respond with the entire selected representation in a 200 (OK) response. That is partly because most clients are prepared to receive a 200 (OK) to complete the task (albeit less efficiently) and partly because clients might not stop making an invalid partial request until they have received a complete representation. Thus, clients cannot depend on receiving a 416 (Range Not Satisfiable) response even when it is most appropriate.

5.1. 範囲~単位~registry

`範囲~単位$~名のための名前空間を定義し, 対応する各~仕様を指す，~registryが、新たに作成された。 それは、 `HTTP Range Unit Registry＠~IANA-a/http-parameters$ にて保守されている。 ◎ The "HTTP Range Unit Registry" defines the namespace for the range unit names and refers to their corresponding specifications. The registry has been created and is now maintained at <http://www.iana.org/assignments/http-parameters>.

   +-------------+---------------------------------------+-------------+
   | Range Unit  | Description                           | Reference   |
   | Name        |                                       |             |
   +-------------+---------------------------------------+-------------+
   | bytes       | a range of octets                     | Section 2.1 |
   | none        | reserved as keyword, indicating no    | Section 2.3 |
   |             | ranges are supported                  |             |
   +-------------+---------------------------------------+-------------+

5.2. 状態s~code登録

`Hypertext Transfer Protocol (HTTP) Status Code Registry＠~IANA-a/http-status-codes$ は、以下の登録により更新された： ◎ The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located at <http://www.iana.org/assignments/http-status-codes> has been updated to include the registrations below:

   +-------+-----------------------+-------------+
   | Value | Description           | Reference   |
   +-------+-----------------------+-------------+
   | 206   | Partial Content       | Section 4.1 |
   | 416   | Range Not Satisfiable | Section 4.4 |
   +-------+-----------------------+-------------+

5.3. ~header登録

以下の~HTTP~headerが “`Message Headers＠~IANA-a/message-headers/$” ~registryの中に登録された。 ◎ HTTP header fields are registered within the "Message Headers" registry maintained at <http://www.iana.org/assignments/message-headers/>.

この文書は、以下の~HTTP~headerを定義する。 それに伴い，以下の恒久的~登録に則って、それらに結付けられた，各 ~registry~entryを更新する （`BCP90$rを見よ）。 ◎ This document defines the following HTTP header fields, so their associated registry entries have been updated according to the permanent registrations below (see [BCP90]):

   +-------------------+----------+----------+-------------+
   | Header Field Name | Protocol | Status   | Reference   |
   +-------------------+----------+----------+-------------+
   | Accept-Ranges     | http     | standard | Section 2.3 |
   | Content-Range     | http     | standard | Section 4.2 |
   | If-Range          | http     | standard | Section 3.2 |
   | Range             | http     | standard | Section 3.1 |
   +-------------------+----------+----------+-------------+

変更~制御者は~IETF-orgである。 ◎ The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".

5.4. ~MIME型~登録

~IANAは `~MIME型の~registry＠~IANA-a/media-types$ `BCP13$r を保守する。 ◎ IANA maintains the registry of Internet media types [BCP13] at <http://www.iana.org/assignments/media-types>.

この文書が、~MIME型 "`multipart/byteranges$c" の仕様になる。 次のものが~IANAにより登録された。 ◎ This document serves as the specification for the Internet media type "multipart/byteranges". The following has been registered with IANA.

6.1. 範囲を利用する~DoS攻撃

拘束されない複数~範囲の要請は、~DoS攻撃に~~感受性が~~高い — 重合する多数の範囲を要請する労力は、要請された~dataを多数の部位で~serveしようとするときに消費される［ 時間, ~memory, 帯域幅 ］に比較して僅かなので。 `~server$は、~~甚しい`範囲~要請$ — 3 個~以上が重合したり, 多数に細切れにされた範囲たちに対する要請 — を［ 無視する／ 合体する／ 却下する ］~OUGHT — 特に，それらの範囲が~~明らかな理由なしに順不同で要請されたとき。 複部位の範囲~要請は、~random~accessを~supportするように設計されていない。 ◎ Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts. Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason. Multipart range requests are not designed to support random access.