Edge（Chromium）请求MP3流发送两次HTTP请求的原因及解决方法

1. Edge（Chromium内核）为何会关闭连接并新建连接？ #

Chromium内核浏览器处理直接输入地址栏的媒体资源时，存在以下触发重连的逻辑：

• 资源类型识别机制：在地址栏输入URL后，浏览器首先发起document类型请求，尝试判断返回内容是否为可渲染文档。由于你的MP3流开头无ID3元数据，浏览器无法快速识别这是音频资源，判定当前响应不符合document类型预期，因此主动断开第一个连接，随后发起专门的media类型请求调用媒体播放引擎处理流数据。
• 流式响应的兼容性问题：服务器无法设置Content-Length头，且是实时生成的流，Chromium的初始document请求在等待资源类型确认时，会因缺少明确的响应长度标识、无法识别媒体类型，触发连接中断，转而使用媒体请求模式重新连接。
• 服务器输出时机的影响：服务器使用ResponseBodyEmitter首次调用output.flush()时触发异常，正好对应第一个连接在服务器刚输出少量数据（16.2kB）时就被浏览器关闭的行为——这是浏览器完成类型识别后主动中断连接的直接结果。

2. 如何阻止该行为？ #

可以通过以下几种方式解决：

• 明确设置Content-Type响应头：在服务器响应中强制设置Content-Type: audio/mpeg，让Chromium一开始就识别出这是音频媒体资源，无需发起document类型的试探请求。
• 添加基础ID3元数据到流开头：即使是最小的空ID3v2头，也能让浏览器快速识别出MP3格式，避免因无法识别类型而切换连接。
• 启用分块传输编码：返回Transfer-Encoding: chunked头，这是流式响应的标准传输方式，让浏览器明确这是分块的实时流，不会因缺少Content-Length而中断初始连接。
• 添加X-Content-Type-Options: nosniff头：强制浏览器严格按照Content-Type标识处理资源，禁止自动嗅探资源类型，从根源上避免浏览器先发起document请求再切换的行为。
• 调整服务器输出策略：使用ResponseBodyEmitter时，先缓存一小段足够识别媒体类型的数据（比如包含基础音频帧的初始数据），再执行第一次flush，确保浏览器收到数据时能立刻识别出媒体类型，不会中途断开连接。

内容的提问来源于stack exchange，提问作者Craynic Cai