背景
对于同一个文件,通过接口来获取二进制文件流的时候,线上部署环境是ok的,可以正常下载,但是本地的vite proxy代理 对于同一个文件展示不同的效果 会直接拒绝访问 报错信息为
            
            
              js
              
              
            
          
          (failed)
net::ERR_INVALID_HTTP_RESPONSE
解决办法 代理中增加二进制处理配置信息 configure
原理
Vite 增加代理配置之所以能解决二进制流的问题,核心原因在于代理服务器对二进制响应的处理方式。
问题根源:Vite 代理的默认行为与二进制流的冲突
Vite 的代理功能基于http-proxy库实现,其默认配置会对响应做一些 "优化处理",比如:
- 
自动添加或修改 Content-Length响应头
- 
可能对响应内容进行字符编码转换 
- 
处理分块传输(chunked)时的格式转换 
这些处理对普通 JSON / 文本响应没问题,但对二进制流(如文件、图片、PDF 等) 会造成严重问题:
- 二进制数据被误当作文本处理导致编码错误
- Content-Length计算错误引发浏览器解析失败(- ERR_INVALID_HTTP_RESPONSE)
- 二进制数据被截断或修改,导致文件损坏
配置生效的关键原因
            
            
              js
              
              
            
          
          configure: (proxy, options) => {
  proxy.on('proxyRes', (proxyRes, req, res) => {
    // 检测二进制流类型的响应
    if (proxyRes.headers['content-type'] && 
        (proxyRes.headers['content-type'].includes('application/octet-stream') ||
         proxyRes.headers['content-type'].includes('application/pdf') ||
         proxyRes.headers['content-type'].includes('image/'))) {
      // 删除Content-Length头
      delete proxyRes.headers['content-length'];
    }
  });
}这段配置的作用是:
- 
识别二进制响应 :通过 Content-Type判断是否为二进制流(文件、图片等)
- 
移除 Content-Length头:- 二进制流的长度计算非常严格,代理自动添加的Content-Length可能与实际内容长度不匹配
- 浏览器发现Content-Length与实际接收的字节数不符时,会判定为无效响应
- 删除该头后,浏览器会根据实际接收的数据流来处理,避免校验失败
 
- 二进制流的长度计算非常严格,代理自动添加的
额外说明
对于二进制流,正确的传输方式通常是:
- 
使用 Transfer-Encoding: chunked分块传输(无需Content-Length)
- 
保持原始二进制编码(不做任何字符转换) 
Vite 的默认代理配置没有针对二进制流做特殊处理,而我们的自定义配置正是修复了这个问题,让二进制数据能够原封不动地从后端传输到前端,从而与线上环境保持一致的行为。
有些文件可以成功,有些不可以的原因 文件大小触发不同传输模式
- 小文件 :后端可能使用Content-Length固定长度传输,且代理计算的长度恰好正确,因此能正常加载。
- 大文件 :后端通常使用Transfer-Encoding: chunked分块传输(不包含Content-Length),但代理可能强行添加了错误的Content-Length,导致浏览器接收时长度不匹配,直接报错。