IIS 10未收到Accept Encoding请求头时返回Content-Length为0故障排查

• IIS 10的动态压缩模块默认优先级高于响应输出逻辑：当请求未携带Accept-Encoding头，或头中没有包含IIS支持的压缩算法（gzip/deflate）时，IIS默认会判定客户端不接受压缩内容，若此时后端Tomcat返回的是未预计算长度的流式响应，IIS不会自动回退到未压缩（identity）的分块传输模式，反而直接丢弃响应体，返回Content-Length: 0。
• 你开启的静态/动态压缩功能仅对携带了符合要求的Accept-Encoding头的请求生效，不会处理无该头的请求的回退逻辑。

1. 修改IIS动态压缩回退规则 #

打开IIS管理器，进入对应站点的「配置编辑器」，定位到system.webServer/httpCompression节点，修改以下属性：

• 将noCompressionForMissingAccept设置为false：允许无Accept-Encoding头的请求返回未压缩内容
• 确认minFileSizeForComp的数值小于你的常规响应大小（500KB），避免响应大小未达阈值触发异常回退逻辑
  修改后保存配置，执行iisreset命令生效。

2. 调整IIS反向代理配置（若使用ARR连接Tomcat和IIS） #

进入ARR的「代理设置」页面：

• 关闭「响应缓冲」功能：开启缓冲时ARR会等待收齐完整响应体再返回给客户端，若响应未压缩且无预定义Content-Length，会直接返回空内容
• 勾选「启用分块响应」选项，允许IIS对无Content-Length的未压缩响应自动添加Transfer-Encoding: chunked头

3. 补充Lambda端请求头配置（可选但推荐） #

在Java Lambda的HTTP请求逻辑中，主动添加Accept-Encoding: gzip, deflate, identity请求头，适配IIS默认压缩规则，Java 8内置gzip解压能力，无需额外代码处理压缩响应。

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