HTTP范围标头

我在看书 并试图找出如何继续下载文件

例如，假设一个文件的长度为100字节，而我拥有所有的100字节。但是，我不知道预期的文件大小应该是多少，因此我请求文件并指定一个如下所示的范围标头：

Range: bytes=100-

GET /resource HTTP/1.1
Host: example.com
Range: bytes=0-9007199254740991

---

这是有效的范围请求吗？

这是语法上有效的请求，但不是可满足的请求。如果您进一步查看该部分，您会看到：

如果语法上有效的字节范围集包括至少一个字节范围规范，其第一个字节位置小于实体主体的当前长度，或者至少一个后缀长度为非零的后缀字节范围规范，则字节范围集是可满足的。否则，字节范围集将无法满足要求如果字节范围集不可满足，服务器应返回状态为416的响应（请求的范围不可满足）。否则，服务器应返回状态为206（部分内容）的响应，其中包含实体主体的可满足范围

因此，我认为在您的示例中，服务器应该返回416，因为它不是该文件的有效字节范围。

正如所建议的，它是一个有效的请求。当客户端请求媒体或恢复下载时，这种情况也很常见

客户机通常会测试服务器是否处理范围请求，而不仅仅是查找

接受范围

响应。Chrome总是在第一次请求获取视频时发送一个

范围：bytes=0-

，所以这是你不能忽视的

每当客户机在其请求中包含

范围：

时，即使格式不正确，它也希望得到部分内容（206）响应。当您在HTML5视频播放期间向前搜索时，浏览器仅请求起点。例如：

Range: bytes=3744-

因此，为了让客户端正确播放视频，服务器必须能够处理这些不完整的范围请求

您可以通过两种方式处理问题中指定的“范围”类型：

首先，您可以使用响应中给定的请求起始点进行响应，然后文件的总长度减去1（请求的字节范围为零索引）。例如：

Range: bytes=3744-

请求：

GET /BigBuckBunny_320x180.mp4 
Range: bytes=100-

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

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

其次，您可以使用请求中给定的起点和开放式文件长度（大小）进行回复。这适用于总长度未知的网络广播或其他媒体。例如：

请求：

GET /BigBuckBunny_320x180.mp4 
Range: bytes=100-

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

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

提示：

您必须始终使用范围中包含的内容长度进行响应。如果范围是完整的，从开始到结束，则内容长度只是差异：

请求： 范围：字节=500-1000

答复： 内容范围：字节500-1000/123456

请记住，该范围是零索引的，因此

range:bytes=0-999

实际上请求的是1000字节，而不是999字节，因此请使用如下方式响应：

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

X-Content-Duration: 7200.00 

或：

但是，如果可能的话，避免使用后一种方法，因为一些媒体播放器试图根据文件大小计算持续时间。如果您的请求是媒体内容，这是我的直觉，那么您应该在响应中包括其持续时间。这是通过以下格式完成的：

X-Content-Duration: 63.23 

这必须是一个浮点。与内容长度不同，此值不必精确。它用于帮助玩家搜索视频。如果你正在流式播放一个网络广播，并且只知道它将持续多长时间，那么最好包括你估计的持续时间，而不是完全忽略它。因此，对于两小时的网络广播，您可以包括以下内容：

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

X-Content-Duration: 7200.00 

对于某些媒体类型，例如webm，还必须包括内容类型，例如：

Content-Type: video/webm 

所有这些都是媒体正常播放所必需的，尤其是在HTML5中。如果你没有给出持续时间，玩家可能会尝试从文件大小中计算出持续时间（以允许搜索），但这并不准确。这很好，对于网络广播或流媒体直播来说是必要的，但对于视频文件的播放来说并不理想。您可以使用FFMPEG之类的软件提取持续时间，并将其保存在数据库甚至文件名中

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

Range: bytes=0-

还有一点：Chrome总是通过以下方式启动其第一个视频请求：

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

Range: bytes=0-

一些服务器将发送一个常规的200响应作为回复，它接受（但播放选项有限），但尝试发送一个206来显示超出服务器处理范围的响应。表示可以忽略范围标题。
与马克·诺瓦科夫斯基的回答相反，由于某些原因，许多人对该回答投了更高的票，是的，这是一个有效且令人满意的要求

事实上，正如Wrikken所指出的，该标准就是这样一个例子。实际上，Apache会按预期响应此类请求（使用206代码），这正是我用来实现渐进式下载的方法，也就是说，只获取随着轮询而实时增长的长日志文件的尾部。
对于2019年遇到Victor Stoddard上述答案的人来说，他们会变得充满希望且目光锐利，请注意：

a） Firefox 41中删除了对X-Content-Duration的支持：

b） 我认为Firefox只支持.ogg音频和.ogv视频，不支持任何其他类型

c） 我看不出它在Chrome中是否得到过支持，但这可能只是我缺乏研究。但在Chrome71中，它的存在或不存在似乎对webm或ogv视频没有任何影响

d） 我找不到“Content-Duration”取代“X-Content-Duration”的任何地方，我认为“X-Content-Duration”的存在时间不够长，因此没有后续的标题名

我认为这意味着，从今天起，如果您想要提供包含