HTTP範囲ヘッダー

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35 を読んでいて、ファイルのダウンロードを続行する方法を見つけようとしていました。

たとえば、ファイルの長さが100バイトで、100バイトすべてがあるとします。ただし、予想されるファイルサイズがわからないため、ファイルを要求し、次のようなRangeヘッダーを指定します。

Range: bytes=100-

これは有効な範囲リクエストですか？

これは構文的に有効な要求ですが、充足可能な要求ではありません。そのセクションをさらに見ると、次のことがわかります。

構文的に有効なbyte-range-setに、first-byte-posがentity-bodyの現在の長さよりも短いbyte-range-specが少なくとも1つ含まれている場合、またはsuffix-byte-range-specが少なくとも1つ含まれている場合-サフィックスの長さがゼロの場合、バイト範囲セットは満足のいくものです。それ以外の場合、バイト範囲セットは満足のいくものではありません。バイト範囲セットが満たされない場合、サーバーはステータス416（要求された範囲が満たされない）の応答を返す必要があります（SHOULD）。それ以外の場合、サーバーは、エンティティ本体の充足可能な範囲を含むステータス206（部分コンテンツ）の応答を返す必要があります。

したがって、あなたの例では、サーバーはそのファイルの有効なバイト範囲ではないため、416を返す必要があると思います。

以下のようWrikkenが提案され、それは有効な要求です。また、クライアントがメディアを要求したり、ダウンロードを再開したりする場合もよくあります。

クライアントは、サーバーがAccept-Ranges応答を探すだけでなく、遠隔要求を処理するかどうかをテストすることがよくあります。Chromeは常にRange: bytes=0-動画の最初のGETリクエストを送信するため、これを却下することはできません。

クライアントがRange:リクエストに含めるときはいつでも、たとえそれが不正な形式であっても、部分的なコンテンツ（206）の応答を期待しています。HTML5ビデオの再生中に前方にシークすると、ブラウザーは開始点のみを要求します。例えば：

Range: bytes=3744-

したがって、クライアントがビデオを適切に再生するには、サーバーがこれらの不完全な範囲の要求を処理できる必要があります。

質問で指定した「範囲」のタイプは、次の2つの方法で処理できます。

最初に、応答で指定された要求された開始点で応答し、次にファイルの全長から1を引いたもので応答できます（要求されたバイト範囲はゼロインデックスです）。例えば：

リクエスト：

GET /BigBuckBunny_320x180.mp4 
Range: bytes=100-

応答：

206 Partial Content
Content-Type: video/mp4
Content-Length: 64656927
Accept-Ranges: bytes
Content-Range: bytes 100-64656926/64656927

次に、リクエストで指定された開始点と自由形式のファイルの長さ（サイズ）で返信できます。これは、全長が不明なWebキャストまたはその他のメディア用です。例えば：

リクエスト：

GET /BigBuckBunny_320x180.mp4
Range: bytes=100-

応答：

206 Partial Content
Content-Type: video/mp4
Content-Length: 64656927
Accept-Ranges: bytes
Content-Range: bytes 100-64656926/*

チップ：

範囲に含まれるコンテンツの長さで常に応答する必要があります。範囲が完全で、開始から終了までの場合、コンテンツの長さは単に違いです。

リクエスト：範囲：bytes = 500-1000

応答：コンテンツ範囲：バイト500-1000 / 123456

範囲はゼロインデックスであるためRange: bytes=0-999、実際には999ではなく1000バイトを要求しているため、次のように応答することに注意してください。

Content-Length: 1000
Content-Range: bytes 0-999/123456

または：

Content-Length: 1000
Content-Range: bytes 0-999/*

ただし、一部のメディアプレーヤーはファイルサイズから期間を把握しようとするため、可能であれば後者の方法は避けてください。私の勘であるメディアコンテンツに対するリクエストの場合は、その期間をレスポンスに含める必要があります。これは、次の形式で実行されます。

X-Content-Duration: 63.23 

これは浮動小数点でなければなりません。とは異なりContent-Length、この値は正確である必要はありません。これは、プレーヤーがビデオを探し回るのを助けるために使用されます。Webキャストをストリーミングしていて、その長さの概要しかわからない場合は、完全に無視するのではなく、推定期間を含めることをお勧めします。したがって、2時間のWebキャストの場合、次のようなものを含めることができます。

X-Content-Duration: 7200.00 

webmなどの一部のメディアタイプでは、次のようなコンテンツタイプも含める必要があります。

Content-Type: video/webm 

これらはすべて、特にHTML5でメディアが正しく再生されるために必要です。期間を指定しない場合、プレーヤーはファイルサイズから（シークを可能にするために）期間を計算しようとする場合がありますが、これは正確ではありません。これは問題なく、Webキャストやライブストリーミングには必要ですが、ビデオファイルの再生には理想的ではありません。FFMPEGなどのソフトウェアを使用して期間を抽出し、データベースまたはファイル名に保存することができます。

X-Content-Durationを優先して段階的に廃止されているContent-Durationので、それも含めます。「0-」リクエストに対する基本的な応答には、少なくとも次のものが含まれます。

HTTP/1.1 206 Partial Content
Date: Sun, 08 May 2013 06:37:54 GMT
Server: Apache/2.0.52 (Red Hat)
Accept-Ranges: bytes
Content-Length: 3980
Content-Range: bytes 0-3979/3980
Content-Type: video/webm
X-Content-Duration: 2054.53
Content-Duration: 2054.53

もう1つのポイント：Chromeは常に最初の動画リクエストを次のように開始します。

Range: bytes=0-

一部のサーバーは、通常の200応答を応答として送信し、それを受け入れます（ただし、再生オプションは制限されます）が、サーバーが範囲を処理するよりも表示するために、代わりに206を送信しようとします。RFC 2616は、範囲ヘッダーを無視することは許容できると述べています。

何らかの理由で多くの人から支持されてきたMarkNovakowskiの回答とは異なり、はい、それは有効で充足可能な要求です。

実際、Wrikkenが指摘したように、標準はまさにそのような例です。実際には、Firefoxは（206コードで）期待どおりにそのような要求に応答します。これは、プログレッシブダウンロードを実装するために使用するものです。つまり、ポーリングでリアルタイムに大きくなる長いログファイルの末尾のみを取得します。

2019年に上記のVictorStoddardの答えに出くわし、希望に満ちて目を凝らしている人々のために、次のことに注意してください。

a）X-Content-DurationのサポートはFirefox 41で削除されました：https： //developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/41#HTTP

b）Firefoxでは.oggオーディオと.ogvビデオでのみサポートされており、他のタイプではサポートされていないと思います。

c）Chromeでこれまでサポートされていたことがまったくわかりませんが、それは私の側の調査が不足しているだけかもしれません。しかし、その存在または不在は、Chrome 71の今日の時点で、webmまたはogvビデオに何らかの影響を与えていないようです。

d）「Content-Duration」が「X-Content-Duration」に置き換わった場所がどこにも見つかりません。「X-Content-Duration」が後継ヘッダー名になるほど長く存続したとは思いません。

これは、今日の時点で、期間がわからないストリーム（ffpegパイプの出力など）を含むwebmまたはogvコンテナーを、ChromeまたはFFに提供し、それらをスクラブ可能にすることを意味すると思います。 HTML 5ビデオ要素、あなたはおそらく運が悪いです。Firefox 64.0は、範囲要求を介してサービスを提供するかどうかに関係なく、これらをスクラブ可能にするために中途半端な試みをしますが、適切と思われる数倍を求めると、ストリームが完全にダウンロードされるまで混乱し、スピニングホイールをスローします。Chromeは試行すらしません。ただうなずいて、ストリーム全体の再生が終了するまでスクラブすることはできません。