HTTP：我应该如何响应“Range: bytes=”当 Range 不受支持时？
如果不支持 Range，对带有标头字段 Range: bytes=278528- 的 GET 请求的正确响应是什么？
读取 HTTP 标头定义 (http://www.w3.org/Protocols/rfc2616 /rfc2616-sec14.html）我认为我至少应该设置：Accept-Ranges: none，但是它明确指出
客户端可以在没有收到所涉及资源的此标头的情况下生成字节范围请求。
因此，如果客户端请求一个范围，我应该：
- 从字节 0 开始回复整个文件？
- 回复一些状态错误？ (400/406/416/501) 请参阅：http://www.w3。 org/Protocols/rfc2616/rfc2616-sec10.html
What is the correct response to a GET request with the header field Range: bytes=278528- if Range is not supported?
Reading the HTTP header definitions (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) i think i should at least set: Accept-Ranges: none, but it clearly states that
Clients MAY generate byte-range requests without having received this header for the resource involved.
So, if a client requests a range, should I:
- Reply with the whole file from byte 0?
- Reply with some status error? (400/406/416/501) see: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
正如规范所述，您可以忽略它。准确地说：
我还没有测试过这个，但规范似乎很清楚。我已经看到了这项工作 - 如果服务器不支持 Range 标头，使用 wget 或 curl 恢复中断的下载将正确地从头开始。
You may ignore it, as the spec says. To be precise:
I have not tested this, but the spec seems pretty clear. I have seen this work — using wget or curl to resume an interrupted download will properly restart from the beginning if the server does not support the Range header.
RFC2616 第 14.35.2 节说：
RFC2616 section 14.35.2 says:
可能性是检查 http 标头，如果存在范围字符串，则解析它，解析到范围，计算跳过并获取位置，从 url 打开文件流，然后，寻求跳过并获取“获取”字节，设置它的响应，发送响应并最终关闭流。
不要忘记使用范围标头进行响应，
不要忽略范围，永远不要在处理大流时这样做。
如果您使用nanohttp，我可以通过示例帮助您
The possibility is check the http header and if there is a range string, parse it, parse to ranges, compute skip and take positions, open file stream from url, then, seek to skip and take 'take ' bytes, setup response of it, send response and finaly close stream.
do not forget to respond with range header
do not ignore range, never when you are working on big streams.
if you are using nanohttp, i can help you out with example
忽略范围请求可能会使 Airplay 服务或其他服务上的播放内容（很大）变得不稳定或不可接受。我知道http不是传输视频的正确协议，但尝试从不接受范围的服务器将视频发送到airplay....
Airplay 使用范围请求...
Ignoring range requests can made play content (which is huge) on airplay service or another unstable or unacceptable. I know that http is not right protokol to transfer video, but try to send video to airplay from server not accepting ranges....
Airplay uses range requests...