内容范围可在Safari中使用，但不能在Chrome中使用

Question

我正在从带有Content-Range标头加上没有缓存标头的Node.js Express服务器流音频文件。相反，这在最新的Safari中可以正常运行，但在Chrome中则不能。

使用HTTP 200流式传输完整音频文件时，我的标题是

{ 'Content-Length': 4724126,
  'Content-Type': 'audio/mpeg',
  'Access-Control-Allow-Origin': '*',
  'Access-Control-Allow-Methods': 'POST, GET, OPTIONS',
  'Access-Control-Allow-Headers': 'POST, GET, OPTIONS',
  Expires: 0,
  Pragma: 'no-cache',
  'Cache-Control': 'no-cache, no-store, must-revalidate' }

，并且可在Chrome和Safari <audio>标签上使用。

使用 HTTP 206 流式传输部分内容时，标头为

{ 'Content-Length': 4724126,
  'Content-Type': 'audio/mpeg',
  'Access-Control-Allow-Origin': '*',
  'Access-Control-Allow-Methods': 'POST, GET, OPTIONS',
  'Access-Control-Allow-Headers': 'POST, GET, OPTIONS',
  Expires: 0,
  Pragma: 'no-cache',
  'Cache-Control': 'no-cache, no-store, must-revalidate',
  'Accept-Ranges': 'bytes',
  'Content-Range': 'bytes 120515-240260/4724126' }

这导致了 Chrome 页面的错误，该页面的标签是<audio>或<video>。

即使Chrome在浏览器中直接使用流式URL时创建的嵌入式媒体代码也无法正常工作，并导致了

提供音频文件以读取本地文件并通过createReadStream api通过Node.js创建文件读取流：

var file = fs.createReadStream(path, {start: range[0], end: range[1]});

我已经发布了服务器here的代码。

[更新]

事实证明，Chrome对Range和Content-Range的请求/响应没有更严格的要求。因此，任何Content-Range响应都必须有一个Range先前的请求。典型的情况是将播放器栏擦到第二个S。api将发送一个"Range"请求，服务器将以“ Content-Range”标头进行响应。就我而言，我是在没有Content-Range的情况下通过普通请求发送"Range"响应。 Safari之所以有效，是因为有更多的street-html投诉，也就是说，严格来说，它在收到"Range"响应之前并不需要"Content-Range"请求。因此，我从响应中删除了“ Content-Range”标头，但它不起作用。 故事的结尾（！）。

为跟进此问题，我也在Chrome bad Range header: Range: bytes=0-的Chromium net-dev论坛中发布了