メインコンテンツまでスキップ

4. 範囲リクエストへの応答 (Responses to a Range Request)

4.1 206 Partial Content​

206 (Partial Content) ステータスコードは、サーバーが、リクエストの Range ヘッダフィールド (3.1 節) に見つかった満たすことが可能な範囲に対応する選択された表現の 1 つ以上の部分を転送することによって、対象リソースへの範囲リクエストを正常に満たしていることを示す。

単一の部分が転送される場合、206 応答を生成するサーバーは、選択された表現のどの範囲が封入されているかを記述する Content-Range ヘッダフィールドと、その範囲からなるペイロードを生成しなければならない (MUST)。例:

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 ...

複数の部分が転送される場合、206 応答を生成するサーバーは、付録 A で定義されている "multipart/byteranges" ペイロードと、multipart/byteranges メディアタイプおよびその必須の boundary パラメーターを含む Content-Type ヘッダフィールドを生成しなければならない (MUST)。単一部分の応答との混同を避けるため、サーバーは複数部分の応答の HTTP ヘッダセクションに Content-Range ヘッダフィールドを生成してはならない (MUST NOT) (このフィールドは代わりに各部分で送信される)。

マルチパートペイロードの各ボディパートのヘッダ領域内で、サーバーは、そのボディパートに封入されている範囲に対応する Content-Range ヘッダフィールドを生成しなければならない (MUST)。選択された表現が 200 (OK) 応答において Content-Type ヘッダフィールドを持つ場合、サーバーは各ボディパートのヘッダ領域に同じ Content-Type フィールドを生成すべきである (SHOULD)。例:

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--

複数の範囲が要求された場合、サーバーは、受信した Range ヘッダフィールドにおいて対応する byte-range-spec が現れた順序にかかわらず、互いに重複する範囲、または複数部分を送信するオーバーヘッドより小さな隙間で隔てられた範囲を結合してもよい (MAY)。multipart/byteranges ペイロードの各部分間の典型的なオーバーヘッドは (選択された表現のメディアタイプと選択された boundary パラメーターの長さに依存するが) 約 80 バイトであるため、多数の小さな離散的な部分を転送する方が、選択された表現全体を転送するよりも効率が悪くなりうる。

サーバーは、単一の範囲の要求に対してマルチパート応答を生成してはならない (MUST NOT)。複数の部分を要求していないクライアントは、マルチパート応答をサポートしていない可能性があるためである。ただし、複数の範囲が要求され、満たすことが可能と判明した範囲が 1 つだけである場合、または結合後に範囲が 1 つだけ残った場合、サーバーはボディパートを 1 つだけ持つ multipart/byteranges ペイロードを生成してもよい (MAY)。multipart/byteranges 応答を処理できないクライアントは、複数の範囲を求めるリクエストを生成してはならない (MUST NOT)。

マルチパート応答ペイロードが生成される場合、サーバーは、満たすことが不可能と見なされた範囲および他の範囲に結合された範囲を除き、受信した Range ヘッダフィールドにおいて対応する byte-range-spec が現れた順序と同じ順序で各部分を送信すべきである (SHOULD)。マルチパート応答を受信するクライアントは、各ボディパートに存在する Content-Range ヘッダフィールドを検査して、そのボディパートに含まれる範囲を判定しなければならない (MUST)。クライアントは、要求したのと同じ範囲を受信することも、要求したのと同じ順序で受信することも当てにできない。

206 応答が生成される場合、サーバーは、上記で要求されたフィールドに加えて、同じリクエストへの 200 (OK) 応答で送信されたであろう以下のヘッダフィールドを生成しなければならない (MUST)。Date、Cache-Control、ETag、Expires、Content-Location、および Vary である。

If-Range ヘッダフィールドを持つリクエストへの応答として 206 が生成される場合、送信側は上記で要求されたフィールド以外の表現ヘッダフィールドを生成すべきではない (SHOULD NOT)。クライアントはそれらのヘッダフィールドを含む以前の応答をすでに持っていると解されるためである。そうでなければ、送信側は、同じリクエストへの 200 (OK) 応答で送信されたであろうすべての表現ヘッダフィールドを生成しなければならない (MUST)。

206 応答はデフォルトでキャッシュ可能である。すなわち、明示的なキャッシュ制御によって別途示されない限り ([RFC7234] の 4.2.2 節を参照)。

4.2 Content-Range​

"Content-Range" ヘッダフィールドは、単一部分の 206 (Partial Content) 応答ではメッセージペイロードとして封入された選択された表現の部分範囲を示すために送信され、マルチパート 206 応答では各ボディパートに封入された範囲を示すために各部分で送信され、416 (Range Not Satisfiable) 応答では選択された表現に関する情報を提供するために送信される。

Content-Range = byte-content-range / other-content-range

byte-content-range = bytes-unit SP
                     ( byte-range-resp / unsatisfied-range )

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

complete-length = 1*DIGIT

other-content-range = other-range-unit SP other-range-resp
other-range-resp = *CHAR

206 (Partial Content) 応答が、受信者が理解しない範囲単位 (2 節) を持つ Content-Range ヘッダフィールドを含む場合、受信者はそれを保存された表現と再結合しようと試みてはならない (MUST NOT)。そのようなメッセージを受信したプロキシは、それを下流に転送すべきである (SHOULD)。

バイト範囲について、送信側は、完全な長さが不明であるか判断が難しい場合を除き、その範囲が抽出された表現の完全な長さを示すべきである (SHOULD)。complete-length の代わりにアスタリスク文字 ("*") を使用することは、ヘッダフィールドが生成された時点で表現の長さが不明であったことを示す。

次の例は、送信側が選択された表現の完全な長さを 1234 バイトと知っている場合を説明している。

Content-Range: bytes 42-1233/1234

また、この 2 番目の例は、完全な長さが不明である場合を説明している。

Content-Range: bytes 42-1233/*

Content-Range フィールド値は、last-byte-pos 値が first-byte-pos 値より小さい byte-range-resp を含む場合、または complete-length 値が last-byte-pos 値以下である場合、無効である。無効な Content-Range の受信者は、受信した内容を保存された表現と再結合しようと試みてはならない (MUST NOT)。

バイト範囲リクエストに対して 416 (Range Not Satisfiable) 応答を生成するサーバーは、次の例のように unsatisfied-range 値を持つ Content-Range ヘッダフィールドを送信すべきである (SHOULD)。

Content-Range: bytes */1234

416 応答における complete-length は、選択された表現の現在の長さを示す。

Content-Range ヘッダフィールドは、その意味論を明示的に記述していないステータスコードに対しては意味を持たない。本仕様では、206 (Partial Content) と 416 (Range Not Satisfiable) のステータスコードのみが Content-Range の意味を記述している。

以下は、選択された表現の合計が 1234 バイトである場合の Content-Range 値の例である。

  • 最初の 500 バイト: Content-Range: bytes 0-499/1234

  • 2 番目の 500 バイト: Content-Range: bytes 500-999/1234

  • 最初の 500 バイトを除くすべて: Content-Range: bytes 500-1233/1234

  • 最後の 500 バイト: Content-Range: bytes 734-1233/1234

4.3 範囲の結合 (Combining Ranges)​

接続が途中で閉じられた場合、またはリクエストが 1 つ以上の Range 指定を使用した場合、応答は表現の部分範囲のみを転送することがある。そのような転送が数回行われた後、クライアントは同じ表現の複数の範囲を受信している可能性がある。これらの範囲は、それらすべてが同じ強いバリデーター ([RFC7232] の 2.1 節) を共通して持つ場合にのみ、安全に結合できる。

対象リソースへの GET リクエストに対して複数の部分応答を受信したクライアントは、それらが同じ強いバリデーターを共有している場合、それらの応答をより大きな連続した範囲に結合してもよい (MAY)。

直近の応答が不完全な 200 (OK) 応答である場合、その応答のヘッダフィールドが結合後の応答に使用され、一致する保存済み応答のヘッダフィールドを置き換える。

直近の応答が 206 (Partial Content) 応答であり、一致する保存済み応答の少なくとも 1 つが 200 (OK) である場合、結合後の応答のヘッダフィールドは、直近の 200 応答のヘッダフィールドから構成される。一致する保存済み応答がすべて 206 応答である場合、ヘッダフィールドが最も新しい保存済み応答が、結合後の応答のヘッダフィールドの供給元として使用される。ただし、クライアントは、新しい応答で提供された他のヘッダフィールド (Content-Range を除く) を使用して、保存済み応答内の対応するヘッダフィールドのすべての出現を置き換えなければならない (MUST)。

結合後の応答メッセージボディは、新しい応答および選択された各応答における部分コンテンツ範囲の和集合から構成される。その和集合が表現の範囲全体から構成される場合、クライアントは、完全な長さを反映する Content-Length ヘッダフィールドを含め、結合後の応答を完全な 200 (OK) 応答であるかのように処理しなければならない (MUST)。そうでなければ、クライアントはその連続した範囲の集合を、次のいずれかとして処理しなければならない (MUST)。結合後の応答が表現の接頭辞である場合は不完全な 200 (OK) 応答、multipart/byteranges ボディを含む単一の 206 (Partial Content) 応答、または各々が Content-Range ヘッダフィールドで示される 1 つの連続した範囲を持つ複数の 206 (Partial Content) 応答。

4.4 416 Range Not Satisfiable​

416 (Range Not Satisfiable) ステータスコードは、リクエストの Range ヘッダフィールド (3.1 節) 内のどの範囲も、選択されたリソースの現在の範囲と重複しないこと、または要求された範囲の集合が、無効な範囲あるいは過剰な小さな範囲や重複する範囲の要求のために拒否されたことを示す。

バイト範囲について、現在の範囲と重複しないとは、すべての byte-range-spec 値の first-byte-pos が、選択された表現の現在の長さより大きかったことを意味する。このステータスコードがバイト範囲リクエストへの応答として生成される場合、送信側は、選択された表現の現在の長さを指定する Content-Range ヘッダフィールド (4.2 節) を生成すべきである (SHOULD)。

例えば:

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

注: サーバーは Range を自由に無視できるため、多くの実装は単に選択された表現全体を 200 (OK) 応答で返すだけである。これは一部には、ほとんどのクライアントが (効率は劣るものの) タスクを完了するために 200 (OK) を受け取る用意があるためであり、一部には、クライアントが完全な表現を受け取るまで無効な部分リクエストを送り続けるのを止めないかもしれないためである。したがって、クライアントは、416 (Range Not Satisfiable) 応答が最も適切である場合でさえ、それを受け取ることを当てにできない。