自研HTTP服务中gzip压缩HTML响应的异常问题咨询

既然现成HTTP服务器能用你的压缩方式正常工作，那问题大概率出在你自己实现的服务器响应头或者压缩后的字节流处理上，我给你列几个最常见的排查方向：

• 检查Content-Encoding头是否正确设置
  Chrome对响应头的校验很严格，你必须在响应头里明确加上Content-Encoding: gzip，而且建议把这个头放在Content-Type之前（虽然HTTP标准没强制顺序，但Chrome对部分头的顺序敏感度较高）。另外，别同时设置多个编码头（比如同时加deflate），否则Chrome可能直接解析失败。

• 确认压缩后的字节流未被篡改
  你可以把自己生成的gzip压缩文件保存下来，用gzip -d命令解压试试，看能不能正常还原成原始HTML。如果解压报错，说明你的压缩过程有问题——比如有没有正确处理原始HTML的字符编码（比如UTF-8）？有没有在压缩前意外添加了多余的空白字节？

• 校验Content-Length头的准确性
  如果你的服务器设置了Content-Length，这个值必须是压缩后字节流的实际长度，绝对不能用原始HTML的长度。很多人在这里踩坑，Chrome收到长度不匹配的响应会直接中断连接或者显示异常。如果不确定长度，干脆去掉Content-Length，改用Transfer-Encoding: chunked传输，这也是现成服务器常用的稳妥方式。

• 验证是否正确处理Chrome的请求头
  Chrome只会在请求头包含Accept-Encoding: gzip, deflate, br时，才接受gzip压缩的响应。你要先确认自己的服务器是否检查了这个请求头——如果客户端没请求gzip你就强行返回压缩内容，Chrome肯定会解析失败。

• 用Chrome开发者工具抓详细错误
  按F12打开DevTools，切换到「Network」标签找到你的请求：

  • 查看「Response Headers」里的Content-Encoding是否存在且正确
  • 看「Response」标签里的内容是乱码还是有明确的错误提示
  • 切换到「Console」标签，有没有类似ERR_CONTENT_DECODING_FAILED的网络错误提示

如果以上排查都没问题，你可以把服务器处理gzip响应的核心代码片段贴出来，这样能更精准定位问题。

内容的提问来源于stack exchange，提问作者Drake M.