HTTP/1.1： 範囲~要請

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

【 この節の内容は、 共通頁 に委譲。 】

1.2. 構文の表記法

【 この節の他の内容は、 共通頁 に委譲。 】

総集的~ABNF にて、他の文書から取込まれた規則, および すべての`~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 より短い場合に該当する — 正誤表 ID 4391 ） 】

`byte-range$p 構文 における［ `first-byte-pos$p, `last-byte-pos$p, `suffix-length$p ］は、~octet数を 10 進~数で表出する。 ~payloadの長さには定義済みの上限はないので、`受信者$は，［ ~decimal数字~列が巨大になり得ることや, 整数~変換の桁溢れ ］を予測して，それらによる~errorを防が~MUST。 ◎ 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する`範囲単位$を指示するために，次を送信して~MAY： ◎ An origin server that supports byte-range requests for a given target resource MAY send

Accept-Ranges: bytes

`~client$は、この~headerを受信していなくても，当の資源に対し `範囲~要請$を`生成し$て~MAY。 ◎ 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" を送信して~MAY： ◎ 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を無視して~MAY。 しかしながら， `生成元~server$／中継~cache は、可能0なときは`~byte範囲$を~supportする~OUGHT — `Range$h は［ 部分的に失敗した転送の効率的な回復や, 巨大な`表現$の部分的な検索取得 ］を~supportするので。 `~server$は、［ `GET$m 以外の要請~methodに伴って受信された `Range$h ~header ］は無視し~MUST。 ◎ 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 ］を無視し~MUST。 `~proxy$は、［ 自身が解さない`範囲単位$を包含する `Range$h ~header ］を破棄して~MAY。 ◎ 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を無視-／却下して~MAY — いずれも， 壊れた~client, あるいは 故意による~DoS攻撃（`6.1$sec）を指示するので。 `~client$は、処理-や転送が，同じ~dataを包摂する単独の範囲より内来的に非~効率的な，複数の範囲を要請する~SHOULD_NOT。 【†おそらく。 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する~SHOULD（概して，完全な`表現$~内にそれらが受信されることになる順序で） — 後側の部位をより早期に要請する必要が特にない限り。 例えば，［ 一連の部位についての内部~目録を伴う，巨大な`表現$ ］を処理している~UAは、後側の部位を最初に要請することも必要になり得る — 特に，`表現$が逆~順序で格納されている頁からなっていて，~UAが一度に 1 頁の転送を望む場合には。 ◎ 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 応答 ］を送信する~SHOULD（`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 応答を送信する~SHOULD。 ◎ 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は，現在の表現~~全体を得るために，もう一度~要請を発行0しなければならなくなる。 ◎ 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を`生成し$~MUST_NOT。 `~server$は、 `Range$h ~headerを包含しない要請~内に受信された `If-Range$h ~headerを，無視し~MUST。 `生成元~server$は、 `Range$h 要請を~supportしない`~target資源$に対する要請~内に受信された `If-Range$h ~headerを，無視し~MUST。 ◎ 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を要請されたように処理する~SHOULD — 合致しない場合には， `Range$h ~headerを無視し~MUST。 `検証子$が `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

`状態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).

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

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

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

［ `選定された表現$のどの範囲が同封されたか, および 範囲を成す~payload ］を述べる `Content-Range$h ~headerを`生成し$~MUST。 例えば： ◎ 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, および［ "`multipart/byteranges$c" 媒体~型とそれに要求される境界~parameter ］を包含する `Content-Type$h ~headerを`生成し$~MUST。

`single-part$p による応答との混同を避けるため、この応答の~HTTP`~header節$内には， `Content-Range$h ~headerを`生成し$~MUST_NOT（この~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を`生成し$~MUST。 `選定される表現$が，［ `200$st 応答においては `Content-Type$h ~headerを持つことになる ］ならば、その同じ `Content-Type$h ~headerを，各~本体~部位~内の~header区域~内に`生成する$~SHOULD。 例えば： ◎ 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より小さな間隙で分離されるもの ］を結合0-して~MAY — 対応0 `byte-range-spec$p が，受信された `Range$h ~header内に出現する順序に関わらず。 "`multipart/byteranges$c" ~payloadの各~部位~間の 代表的な~overheadは， 80 ~byte程度なので、細切れにされた多数の部位を転送するのは，［ `選定された表現$の媒体~型, および 選択された境界~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$は、単独の範囲に対する要請に対し，`複部位$応答を`生成し$~MUST_NOT — 複数の部位を要請しなかった~clientは，`複部位$応答を~supportしないかもしれないので。 しかしながら，`~server$は、複数の範囲が要請されていて, かつ［ 唯一の範囲が`充足可能$として見出された, または 結合0-した後に 1 個の範囲のみ残った ］ならば、単独の本体~部位のみを伴う "`multipart/byteranges$c" ~payloadを`生成し$て~MAY。 "`multipart/byteranges$c" 応答を処理できない`~client$は、複数の範囲を依頼する要請を`生成し$~MUST_NOT。 ◎ 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内に出現する対応0 `byte-range-spec$p と同じ順序で，各~部位を送信する~SHOULD — ［ `充足不可$と判断される, あるいは他の範囲に結合0される ］ような範囲たちは除外した上で。 `複部位$応答を受信した`~client$は、各~本体~部位~内に在る `Content-Range$h ~headerを検分して，その本体~部位~内にどの範囲が包含されているかを決定し~MUST — ~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 ］を`生成し$~MUST ⇒ `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

`受信者$は、［ 自身が解さない `範囲単位$を伴う `Content-Range$h ~header ］を包含する`206$st 応答に対しては，それを格納-済み表現と再結合しようと試みては~MUST0。 その種の~messageを受信した`~proxy$は、それを`下流$へ回送する~SHOULD。 ◎ 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範囲$に対しては、`送信者$は，［ 抽出された範囲の表現 ］の完全な長さを指示する~SHOULD — ［ その長さが未知, または それを決定するのが困難 ］であるのでない限り。 `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 の`受信者$は、受信された内容と格納-済みの表現を再結合しようと試みては~MUST0。 ◎ 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 ］を送信する~SHOULD — 次の例のように： ◎ 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の意味論を明示的に述べないような `状態code$に対しては，意味を持たない。 この仕様においては、`状態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 と記す） ］とを，より大きな連続的な範囲に結合して~MAY（結合した結果の応答を，以下 `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 内の各 応答 ］内の対応0~headerたちすべての~instance ］を置換し~MUST。 ◎ 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

【 正誤表に報告あり： 選定された資源を `選定された表現$に置き換える — Reported: 2016-04-13 】

`~byte範囲$に対しては、現在の全範囲と重合しないことは、どの `byte-range-spec$p 値の `first-byte-pos$p も，`選定された表現$の現在の長さより大きいことを意味する。 `送信者$は、`~byte範囲$の要請に対する応答~内に，この`状態code$を`生成する$ときは，［ `選定された表現$の現在の長さを指定する `Content-Range$h ~header ］を`生成する$~SHOULD。 ◎ 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には［ 完全な表現を受信するまで，妥当でない`部分的~要請$の発行0を停止しない ］ものもあるためである。 したがって，~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. 範囲単位~登記簿

`範囲単位$~名のための名前空間を定義し, 対応する各~仕様を指す，登記簿が、新たに作成された。 それは、 HTTP Range Unit Registry にて保守されている。 ◎ 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. 状態code登録

Hypertext Transfer Protocol (HTTP) Status Code Registry は、以下の登録により更新された： ◎ 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” 登記簿の中に登録された。 ◎ HTTP header fields are registered within the "Message Headers" registry maintained at <http://www.iana.org/assignments/message-headers/>.

この文書は、以下の~HTTP~headerを定義する。 それに伴い，以下の恒久的~登録に則って、それらに結付けられた，各 登記簿~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. ~Internet媒体~型~登録

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

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

   Type name:  multipart

   Subtype name:  byteranges

   Required parameters:  boundary

   Optional parameters:  N/A

   Encoding considerations:  only "7bit", "8bit", or "binary" are
      permitted

   Security considerations:  see Section 6

   Interoperability considerations:  N/A

   Published specification:  This specification (see Appendix A).

   Applications that use this media type:  HTTP components supporting
      multiple ranges in a single request.

   Fragment identifier considerations:  N/A

   Additional information:

      Deprecated alias names for this type:  N/A

      Magic number(s):  N/A

      File extension(s):  N/A

      Macintosh file type code(s):  N/A

   Person and email address to contact for further information:  See
      Authors' Addresses section.

   Intended usage:  COMMON

   Restrictions on usage:  N/A

   Author:  See Authors' Addresses section.

   Change controller:  IESG

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

拘束されない複数~範囲の要請は、~DoS攻撃に~~感受性が~~高い — 重合する多数の範囲を要請する労力は、要請された~dataを多数の部位で~serveしようとするときに消費される［ 時間, ~memory, 帯域幅 ］に比較して僅かなので。 `~server$は、~~甚しい`範囲~要請$ — 3 個~以上が重合したり, 多数に細切れにされた範囲たちに対する要請 — を［ 無視する／ 結合0する／ 却下する ］~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.