HTTP范围标头

Question

我正在阅读http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35 并试图找出如何继续文件下载.

例如,假设一个文件长度为100个字节,并且我有100个字节.但是,我不知道预期的文件大小应该是什么,所以我要求文件并指定一个如下所示的Range标头:

Range: bytes=100-

这是一个有效的Range请求吗？

Answer 1

正如Wrikken建议的那样,这是一个有效的请求.当客户端请求媒体或恢复下载时,这也很常见.

客户端通常会测试服务器是否处理远程请求而不仅仅是查找Accept-Ranges响应.Chrome 总是发送一个Range: bytes=0-带有第一个GET请求的视频,所以这是你无法解雇的.

每当客户Range:在其请求中包括,即使它的格式不正确,它也期望部分内容(206)响应.当您在HTML5视频播放期间向前搜索时,浏览器仅请求起始点.例如:

Range: bytes=3744-

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

您可以通过两种方式处理在问题中指定的"范围"类型:

首先,您可以使用响应中给出的请求起始点进行回复,然后文件的总长度减去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

其次,您可以使用请求中给出的起点和开放文件长度(大小)进行回复.这适用于总长度未知的网络广播或其他媒体.例如:

请求:

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

提示:

您必须始终使用范围中包含的内容长度进行响应.如果范围是完整的,从头到尾,那么内容长度就是差异:

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

响应:内容范围:字节500-1000/123456

请记住,范围是零索引的,所以Range: bytes=0-999实际上是请求1000个字节,而不是999,所以请回复:

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

要么:

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

但是,如果可能的话,请避免使用后一种方法,因为某些媒体播放器会尝试从文件大小中确定持续时间.如果您的请求是针对媒体内容的,这是我的预感,那么您应该在响应中包含其持续时间.这是通过以下格式完成的:

X-Content-Duration: 63.23 

这必须是一个浮点.与Content-Length此不同,此值不必准确.它用于帮助玩家寻找视频.如果您正在播放网络直播,并且只知道它会持续多长时间,那么最好包括您的估计持续时间而不是完全忽略它.因此,对于两小时的网络广播,您可以包含以下内容:

X-Content-Duration: 7200.00 

对于某些媒体类型,例如webm,您还必须包含内容类型,例如:

Content-Type: video/webm 

所有这些都是媒体正常播放所必需的,特别是在HTML5中.如果你没有给出一个持续时间,玩家可能会试图从文件大小中找出持续时间(允许搜索),但这不准确.这很好,是网络直播或直播所必需的,但不适合播放视频文件.您可以使用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

还有一点:Chrome始终使用以下内容启动第一个视频请求:

Range: bytes=0-

一些服务器会发送一个常规的200响应作为回复,它接受(但回放选项有限),但尝试发送206代替显示而不是服务器处理范围.RFC 2616表示忽略范围标题是可以接受的.

Answer 2

这是一个语法上有效的请求,但不是一个令人满意的请求.如果您仔细查看该部分,您会看到:

如果语法上有效的字节范围集包括至少一个byte-range-spec,其first-byte-pos小于entity-body的当前长度,或者至少有一个后缀-byte-range-spec,则为non - 零后缀长度,然后字节范围设置是可满足的.否则,字节范围设置是不可满足的.如果字节范围集不可满足,服务器应该返回状态为416的响应(请求范围不可满足).否则,服务器应该返回状态为206(部分内容)的响应,其中包含实体主体的可满足范围.

所以我认为在你的例子中,服务器应该返回416,因为它不是该文件的有效字节范围.

Answer 3

与Mark Novakowski的答案相反,由于某些原因,许多人赞成这一点,是的,这是一个有效且令人满意的要求.

事实上,正如Wrikken指出的那样,标准就是这样一个例子.在实践中,Firefox响应预期的这些请求(使用206代码),这正是我用来实现渐进式下载的,也就是说,只获得一个长日志文件的尾部,该文件通过轮询实时增长.

Answer 4

对于那些在 2019 年偶然发现 Victor Stoddard 上面的答案并变得充满希望和眼睛的人，请注意：

a) Firefox 41 中删除了对 X-Content-Duration 的支持：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 甚至不尝试，它只是不显示，并且在整个流播放完毕之前根本不会让您擦洗。