当 http 标头中未设置 Accept-Ranges 时，浏览器音频播放失败；为什么？
我最近在 Firefox 或 Chrome 中打开音频文件时发现了一些（令我惊讶的）事情。如果我不指定 HTTP 响应标头“Accept-Ranges: bytes”，则 Firefox 将无法在播放结束之前确定 ogg 文件的长度（以秒为单位）。 Chrome 会发现 ogg 文件的长度（以秒为单位），但音频播放器在到达末尾时似乎崩溃，并且在崩溃后拒绝重新播放该文件。其他浏览器未测试。
有效的 Http 响应标头：
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: application/ogg
Content-Length: 245646
失败的 Http 响应标头：
HTTP/1.1 200 OK
Content-Type: application/ogg
Content-Length: 245646
这对我来说很奇怪，因为我没有使用任何部分内容范围。我的服务器实现甚至不支持它们（所以我认为我的服务器当它说“Accept-Ranges：bytes”时可能在撒谎）。我当然不明白为什么在浏览器中播放需要这个标头。两个浏览器是否都存在错误，当我不设置 Accept-Ranges 标头时会暴露这些错误？这对我来说似乎不太可能。谁能解释一下吗？
谢谢！
I recently discovered something (that surprises me) when opening an audio file in firefox or chrome. If I don't specify the HTTP response header "Accept-Ranges: bytes", firefox won't be able to determine the length of the ogg file (in seconds) before reaching the end in playback. Chrome will discover the length of the ogg file (in seconds), but the audio player appears to crash when it reaches the end, and refuses to re-play the file after the crash. Other browsers were not tested.
Working Http response headers:
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: application/ogg
Content-Length: 245646
Failing Http response headers:
HTTP/1.1 200 OK
Content-Type: application/ogg
Content-Length: 245646
This is strange to me, because I'm not using any partial-content ranges. My server implementation doesn't even support them (so I think my server might be lying when it says "Accept-Ranges: bytes"). I certainly don't see why this header should be required for playback within the browser. Do both browsers just have bugs, which are exposed when I don't set the Accept-Ranges header? This seems unlikely to me. Can anyone explain?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不确定这是一个错误还是只是对标准的歪曲解释 - 第 14.5 节。标准规定可以但不是必须...
OTOH 它可以是为了能够使用音频流和/或搜索等。实现的音频播放模块需要这个标头...您可以尝试如果您提交会发生什么“接受范围：无”...如果它们有点符合 http 1.1，那么它就可以工作...
Not sure this is a bug or just a skewed interpretation of the standard - section 14.5 . The standard states MAY and not MUST...
OTOH it can be that for being able to use an audio-stream and/or seeking etc. the implemented audio playback modules need this header... you can try out what happens if you submit "Accept-Ranges: none"... if they are a bit http 1.1 conforming than it just works...