3

我正在从带有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' }

这导致or标记所在的Chrome页面出现错误。<audio><video>

即使是 Chrome 在浏览器中使用流式 URL 时创建的嵌入式媒体标签也无法正常工作，并导致了这种情况

在此处输入图像描述

createReadStream音频文件通过 Node.js API读取本地文件并创建文件读取流：

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

我在这里发布了服务器的代码。

[更新]

事实证明，Chrome 并没有对请求/响应更加Range严格Content-Range。所以任何Content-Range响应都必须有一个Range先前的请求。典型的情况是将播放器栏擦洗到第二个 S。api 将发送"Range"请求，服务器将响应“Content-Range”标头。就我而言，我是通过Content-Range没有"Range". Safari 之所以有效，是因为它的street-html抱怨更多，即它并不严格要求在响应"Range"之前提出请求"Content-Range"。所以，我从我的回复中删除了“Content-Range”标题，但它不起作用。故事的结局 （！）。

为了跟进这个问题，我也在 Chromium net-dev 论坛的Chrome bad Range 标头中发布： Range: bytes=0-

4

0 回答 0