状態符号 206 (HTTP)

[15] 206 は、応答に含まれるのが要求された資源の一部であることを表す状態符号です。

仕様書

[1] RFC 7233 - Hypertext Transfer Protocol (HTTP/1.1): Range Requests (2014-09-11 09:57:55 +09:00 版) https://tools.ietf.org/html/rfc7233#section-4.1
[5] RFC 7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching (2014-09-11 10:19:59 +09:00 版) https://tools.ietf.org/html/rfc7234#section-3.1

意味

[3] 206 は、要求の Range: ヘッダーで指定された各範囲について、選択された表現に関して満足可能なものに対応する各部分を転送することにより、対象資源の範囲要求を満足することに成功していることを表す状態符号です >>1。

構文

[11] 206 応答では、 200 応答だったら送っていたであろう次のヘッダーを生成しなければなりません >>1。

[16] 200 の時送らないものは、送る必要はありません。

[17] 304 でも同様の規定があります。

[12] 要求に If-Range: ヘッダーが指定されていた場合には、鯖は他の表現ヘッダーを生成するべきではありません。クライアントは既に以前の要求で受け取っているはずだからです。 If-Range: ヘッダーが指定されていない場合には、 200 応答だったら送っていたであろう表現ヘッダーをすべて生成しなければなりません。 >>1

[13] 表現ヘッダー (「representation header fields」) は HTTP 仕様書で定義されていない用語なので、何を指しているのか不明です。表現メタデータが近そうですが...

[18] 304 はキャッシュに関して有用なヘッダーであれば指定しても良いとしていますが、 If-Range: はキャッシュの更新のためのものではありませんから、相当する規定がないものと思われます。

[4] 206 応答の構築時の構文的制約については、範囲要求の項も参照してください。

[8] 206 応答の payload body は元のデータの一部分ですから、 Content-Type: に記述されたMIME型の仕様に従ったデータになっているとは限りません。単独では意味を成さないデータかもしれません。

文脈

[9] 206 応答は範囲要求に対する応答で使われます。

範囲要求では他に 200 が使われる場合もあります。

[19] 範囲選択の後に他の実現値操作が適用される場合には、 226 が使われます。

[20] キャッシュは、 226 応答から 206 応答を作ることも認められています。

226 の項を参照。

処理モデル

[10] クライアントは、 multipart/byteranges の本体部分が Range: に指定した範囲の順序であると仮定できません。クライアントは各本体部分の Content-Range: ヘッダーを調べなければなりません >>1。

[14] 206 応答は、キャッシュ可能です >>1。

[6] キャッシュは、 Range: と Content-Range: と範囲単位に対応しているなら、 206 応答を蓄積して構いません。また不完全な 200 応答を 206 応答として蓄積して構いません。 >>5

[7] 範囲要求も参照。

歴史

[2] RFC 2068・2616 (HTTP/1.1) 10.2.7 206 Partial Content

The server has fulfilled the partial GET request for the resource. The request ~~must~~ MUST have included a Range header field (section ~~14.36~~ 14.35) indicating the desired range, and MAY have included an If-Range header field (section 14.27) to make the request conditional.

サーバーはその資源についての部分 GET を満たしました。要求は望ましい範囲を示した Range 頭欄を含んでいなければなりませんで、要求を条件的にする If-Range 頭欄を含んでいてもかまいません。

The response MUST include the following header fields:
~~either~~ Either a Content-Range header field (section ~~14.17~~ 14.16) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields for each part. If ~~multipart/byteranges is not used, the~~ a Content-Length header field is present in the response, its value MUST match the actual number of OCTETs transmitted in the message-body.

応答は次の頭欄を含んでいなければなりません:

この資源に含まれている範囲を示す Content-Range 頭欄又は multipart/byterange Content-Type であって各部分が Content-Range 欄を含んでいるもののいずれか。 Content-Length 頭欄が応答に含まれるなら、その値は message-body 中の転送される OCTET の実際の数と一致しなければなりません。

Date
ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant

Date
同じ要求についての 200 応答で送られるであろうなら、 ETag 及び/又は Content-Location
同じ変種についての以前の応答で送られたものと異なるかもしれない field-value であれば、 Expires, Cache-Control 及び/又は Vary

If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.

206 応答が強いキャッシュ検証を使った If-Range 要求の結果であるなら、応答は他の実体頭を含むべきではありません。応答が弱い検証を使った結果であるなら、応答は他の実体頭を含んではなりません。これによってキャッシュされている実態本体と更新された頭の不一致を防ぐことができます。これ以外の場合には、応答は同じ要求に対する 200 応答が返すであろう実体頭を全て含まなければなりません。