[12] Content-Range:
ヘッダーは、
資源のうちどの部分が含まれているかを表します。
[4] Content-Range:
ヘッダーは、 206
応答において当該メッセージの payload、
または当該本体部分に含まれる選択された表現の範囲を表します >>3。
[5] Content-Range:
ヘッダーは、 416
応答において選択された表現についての情報を提供します >>3。
[6] 値は範囲単位、 SP
、範囲の記述を並べたものです。
範囲の記述は範囲単位に依存しますが、0文字以上の列とされています。 >>3
[9] 受信者は、 206
応答が理解できない範囲単位の
Content-Range:
ヘッダーを含んでいる時、
あるいは非妥当な範囲の値を含んでいる時、
蓄積された表現にこれを結合しようと試みてはなりません。
串は下流へ転送するべきです。 >>3
[13] 受信者は Content-Range:
が含まない範囲の応答を無視するべきと思われますが、
仕様上明記されていません。
[521] 起源鯖は、対象資源に PUT
を認めている場合で、
要求に Content-Range:
ヘッダーが含まれる場合、
payload が一部分しか含まれないのに誤って PUT
を使っている可能性があるため、 400
応答を送信しなければなりません
>>507。
[18] Google BigQuery >>17 や yfrog >>19
はファイルの一部のアップロードのために PUT
で Content-Range:
を使っています。
The Content-Range entity-header is sent with a partial entity-body to specify where in the full entity-body the partial body should be applied. Range units are defined in section 3.12.
inserted. It also indicates the total size of the full entity-body. When a server returns a partial response to a client, it must describe both the extent of the range covered by the response, and the length of the entire entity-body.
Content-Range
実体頭欄は、部分 entity-body
と共に送信して、その部分本体が完全 entity-body
のどこに適用されるべきかを指定します。 範囲単位は 3.12 節で定義しています。 この欄は完全 entity-body
の全体の寸法も示します。サーバーが部分応答をクライアントに返す時は、その応答により覆われる範囲と entity-body
全体の長さを記述しなければなりません。
Content-Range
= "Content-Range" ":" content-range-spec]]content-range-spec = byte-content-range-spec
byte-content-range-spec = bytes-unit SP first-byte-pos "-" last-byte-pos "/" entity-length
byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( instance-length | "*" )
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos) | "*"
entity-lengthinstance-length = 1*DIGIT
The header SHOULD indicate the total length of the full entity-body, unless this length is unknown or difficult to determine. The asterisk "*" character means that the instance-length is unknown at the time when the response was generated.
この頭は完全な entity-body
の全体の長さが未知であるか、
又は決定するのが難しい場合を除いては、この長さを示すべきです。
星印 *
文字は、その応答が生成された時点で
instance-length
が未知であることを意味します。
Unlike byte-ranges-specifier values (see section 14.35.1), a
byte-content-range-spec maybyte-range-resp-spec MUST only specify one range, andmustMUST contain absolute byte positions for both the first and last byte of the range.
byte-ranges-specifier
値とは異なり、
byte-range-resp-spec
は一つの範囲だけを指定しなければならず、
範囲の最初と最後のバイトの絶対バイト位置を含まなければなりません。
A byte-content-range-spec with a byte-range-resp-spec whose last-byte-pos value is less than its first-byte-pos value, or whose
entity-lengthinstance-length value is less than or equal to its last-byte-pos value, is invalid. The recipient of an invalid byte-content-range-spec MUST ignore it and any content transferred along with it.
byte-range-resp-spec
つきの byte-content-range-spec
であってその last-byte-pos
が
first-byte-pos
値よりも小さなものや、
instance-length
値が last-byte-pos
値以下のものは不当です。不当な byte-content-range-spec
の受信者は、この byte-content-range-spec
及びそれと共に転送された内容を全て無視しなければなりません。
A server sending a response with status code 416 (Requested range not satisfiable) SHOULD include a Content-Range field with a byte-range-resp-spec of "*". The instance-length specifies the current length of the selected resource. A response with status code 206 (Partial Content) MUST NOT include a Content-Range field with a byte-range-resp-spec of "*".
状態符号 416
(要求された範囲は満足されませんでした)
の応答を送信するサーバーは、 byte-range-resp-spec
が *
の Content-Range
欄を含めるべきです。 instance-length
が選択された資源の現在の長さを指定します。
状態符号 206
(部分内容) の応答は
byte-range-resp-spec
が *
の Content-Range
欄を含んでいてはなりません。
Examples of byte-content-range-spec values, assuming that the entity contains a total of 1234 bytes:
実体が全部で 1234 バイトあるとして、 byte-content-range-spec
値の例を示します:
o. The first 500 bytes 最初の500バイト- bytes 0-499/1234
o. The second 500 bytes 次の500バイト- bytes 500-999/1234
o. All except for the first 500 bytes 最初の500バイト以外全て- bytes 500-1233/1234
o. The last 500 bytes 最後の500バイト- bytes 734-1233/1234
When an HTTP message includes the content of a single range (for example, a response to a request for a single range, or to a request for a set of ranges that overlap without any holes), this content is transmitted with a Content-Range header, and a Content-Length header showing the number of bytes actually transferred. For example,
単一の範囲の内容を含む HTTP メッセージ (例えば、
単一の範囲の要求への応答又は穴なしに重なり合う範囲の集合の要求への応答)
の場合は、この内容は Content-Range
頭と共に転送され、
Content-Length
頭は実際に転送されるバイト数を示します。
例えば、
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/gifWhen an HTTP message includes the content of multiple ranges (for example, a response to a request for multiple non-overlapping ranges), these are transmitted as a multipart
MIMEmessage. The multipartMIME content-typemedia type used for this purpose isdefined in this specification to be "multipart/byteranges""multipart/byteranges" as defined in appendix 19.2. See appendix19.2 for its definition19.6.3 for a compatibility issue.
HTTP メッセージが複数の範囲を含む場合 (例えば、
複数の重なり合わない範囲の要求への応答) には、
複数部分メッセージとして転送されます。
この目的で使う複数部分媒体型は附属書 19.2 節で定義している
multipart/byterange
です。互換性の問題については附属書
19.6.3 節を参照してください。
A response to a request for a single range MUST NOT be sent using the multipart/byteranges media type. A response to a request for multiple ranges, whose result is a single range, MAY be sent as a multipart/byteranges media type with one part. A client that cannot decode a
MIMEmultipart/byteranges messageshould notMUST NOT ask for multiple byte-ranges in a single request.
単一の範囲の要求への応答は multipart/byterange
媒体型を使って送ってはなりません。
複数範囲の要求への応答であってその結果が単一範囲であるものは、
1つの部分の multipart/byterange
媒体型で送っても構いません。
multipart/byterange
メッセージを復号できないクライアントは、
複数の byte-range
を単一の要求で依頼してはなりません。
When a client requests multiple byte-ranges in one request, the server SHOULD return them in the order that they appeared in the request.
クライアントが複数の byte-range
を1つの要求で要求した時は、サーバーは要求中に出現した順でこれを返すべきです。
If the server ignores a byte-range-spec because it is syntactically invalid, the server
shouldSHOULD treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing the full entity).The reason is that the only time a client will make such an invalid request is when the entity is smaller than the entity retrieved by a prior request.
byte-range-spec
が構文的に不当であるためにサーバーがこれを無視する場合は、
サーバーは要求に不当な Range
頭欄が存在しなかったものとして扱うべきです。
(通常、これは完全な実体を含んだ 200
応答を返すことを意味します。) 理由は、クライアントがそのような不当な要求を作るのは実態が以前の要求で取り出された実体より小さい時だけだからです。
If the server receives a request (other than one including an If-Range request-header field) with an unsatisfiable Range request-header field (that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected resource), it SHOULD return a response code of 416 (Requested range not satisfiable) (section 10.4.17).
サーバーが (If-Range
要求頭欄を含んでいない)
満足されない Range
要求頭欄
(つまり、 byte-range-spec
値の全てにおいて first-byte-pos
値が選択された資源の現在の長さよりも大きいもの。) を持った要求を受け取ったときには、
サーバーは応答符号 416
(要求された範囲は満足されませんでした)
を返すべきです。
Note: clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for an unsatisfiable Range request-header, since not all servers implement this request-header.
注意 : 全てのサーバーはこの要求頭を実装しているわけではありませんから、
クライアントは満足されない Range
要求頭欄にサーバーが
200
(OK) 応答ではなく 416
(要求された範囲は満足されませんでした)
応答が送ることに依存することはできません。
[1] 参照しろと書いてある RFC 2616 19.6.3 (RFC 2068 からの変更点) にはたいして面白いことは書いてありませんでした。
[23] WebDAV の MS の拡張には
DAV:contentrange
があります。
>>22
[22] [MS-XWDSEARCH].pdf, , https://download.microsoft.com/download/5/0/1/501ED102-E53F-4CE0-AA6B-B0F93629DDC6/Exchange/%5BMS-XWDSEARCH%5D.pdf#page=10
CHAR
としていますが >>3、これは RFC 723x のどこでも定義されていません。Range:
との整合性を考慮するとVCHAR
の誤りで、U+0021
-U+007E
と解釈するべきでしょう。 RFC 2616CHAR
だとするとU+0000
-U+00FF
が認められますが、改行なども含まれていて不適切です。