Accept-Encoding 头域导致 content-length 响应头丢失问题分析

Posted 2021-06-28 毕小宝

背景

最近开发工作内容是用 Netty 实现 http 服务，测试客户端用 Postman ，直接用默认的请求头，结果被 Accept-Encoding 困扰了大半天，本文总结两个默认请求头域的坑点。

Accept-Encoding 导致下载请求失败

问题描述：一个用 Netty 实现的文件下载请求，用 postman 模拟时发现，默认请求头有 Accept-Encoding:gzip, deflate, br 时，即使后端 Netty 响应设置了 content-length 头，也会收不到数据。

表现为：

一直是进度条状态，无法显示响应文件，此时收到的响应头域是 transfer-encoding：chunked，把后端已经设置的 Content-Length 头域给覆盖了。

解决办法：去掉该请求头后，响应正常返回了文件，且有长度：

Body 页有了响应文件内容：

事实上，反复测试后发现，只要有该头域，大部分情况下，响应内容都没有 content-length ，被 transfer-encoding：chunked 替代了。

Content-Length

如果请求头中的 Content-Length 去掉，则会导致请求被发送两次。

启示录

Accept-Encoding 这个头对文件下载请求的影响，上个月写文件下载请求时已经碰到过了，但是没有整理记录，今天联调测试的时候又出现这个问题，纠结了半天突然又想起来了。

网上的也有说这个头域加上后导致无法解码的问题，即使服务端响应头也有该值，还是无法正常解码。为甚呢？