Content-Range:

Content-Range: ヘッダー (HTTP)

[12] Content-Range: ヘッダーは、 資源のうちどの部分が含まれているかを表します。

仕様書

意味

[4] Content-Range: ヘッダーは、 206 応答において当該メッセージpayload、 または当該本体部分に含まれる選択された表現の範囲を表します >>3

[5] Content-Range: ヘッダーは、 416 応答において選択された表現についての情報を提供します >>3

[10] それ以外の状態符号では、意味を持ちません >>3

構文

[6] 値は範囲単位SP、範囲の記述を並べたものです。 範囲の記述は範囲単位に依存しますが、0文字以上の列とされています。 >>3

[7] 範囲の記述に使える文字を RFC 7233CHAR としていますが >>3、これは RFC 723x のどこでも定義されていません。 Range: との整合性を考慮すると VCHAR の誤りで、 U+0021-U+007E と解釈するべきでしょう。 RFC 2616 CHAR だとすると U+0000-U+00FF が認められますが、改行なども含まれていて不適切です。
  1. 範囲単位
  2. SP
  3. *
    1. U+0021-U+007E
[8] この構文では Content-Range: ヘッダーの値が範囲単位SP だけで終わることがありますが、 欄値の項にある通り、 RFC 7230 にあるヘッダー一般の構文に反しています。
[11] 範囲単位依存の構文については、各範囲単位の項を参照してください。

文脈

[14] 206 応答の場合については、 206 の項を参照してください。

[15] バイト範囲範囲要求に対する 416 応答の場合については、バイト範囲の項を参照してください。

処理

[9] 受信者は、 206 応答が理解できない範囲単位Content-Range: ヘッダーを含んでいる時、 あるいは非妥当な範囲の値を含んでいる時、 蓄積された表現にこれを結合しようと試みてはなりません下流転送するべきです>>3

[13] 受信者Content-Range: が含まない範囲の応答を無視するべきと思われますが、 仕様上明記されていません。

[521] 起源鯖は、対象資源PUT を認めている場合で、 要求Content-Range: ヘッダーが含まれる場合、 payload が一部分しか含まれないのに誤って PUT を使っている可能性があるため、 400 応答を送信しなければなりません >>507

[20] この規定は RFC 723x で追加されました。

[18] Google BigQuery >>17yfrog >>19 はファイルの一部のアップロードのために PUTContent-Range: を使っています。

[21] この種の Web API は世間一般でほとんど使われていない PUT メソッドの数少ない正当な利用例だったのに、梯子を外して不適合にしちゃう RFC 723x はまじ鬼畜wwwww

歴史

[2] RFC 2068 14.17・RFC 2616 14.16 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 全体の長さを記述しなければなりません。

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 may byte-range-resp-spec MUST only specify one range, and must MUST 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-length instance-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-posfirst-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/gif

When 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 MIME message. The multipart MIME content-type media type used for this purpose is defined in this specification to be "multipart/byteranges" "multipart/byteranges" as defined in appendix 19.2. See appendix 19.2 for its definition 19.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 MIME multipart/byteranges message should not MUST 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 should SHOULD 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 からの変更点) にはたいして面白いことは書いてありませんでした。