IIS 8.5静态压缩缺少内容编码响应标头，但失败的请求跟踪显示了使用gzip的压缩

Question

我发现Content-Encoded响应标头丢失了，特别是Content-Encoded：gzip。我正在使用static content compression。从未安装dynamic content compression功能。我安装了它，启用了它，然后再次测试。这次，响应中出现了Content-Encoded：gzip。问题是，为什么响应头出现在动态内容压缩中而不出现在静态内容压缩中？我相当确定IIS将gzip应用于静态内容压缩。这是为什么：

1. 我有一个IIS URL重写出站规则，该规则可以修改HTML页面上的响应。出站规则产生错误500.52，URL重写模块错误-编码HTTP响应的内容（“ gzip”）时，不能应用出站重写规则。规则不是问题，仅是据报道gzip被应用的证据。我禁用了该规则。这是线索1。

2. 我启用了线索2 Failed Request Tracing，并观察到不仅应用了静态压缩，而且StaticFileModule将压缩文件存储在以下位置：C：\ INETPUB \ TEMP \ IIS TEMPORARY COMPRESSED FILES \我的网站\ $ ^ _ GZIP_D ^ \ INETPUB \ WWWROOT \ TEST.HTML。

我阅读了IIS HTTP Compression上的Microsoft文档，并且-我可能错了-我没有看到任何建议使用gzip进行静态压缩的语言。基于以上两个提示，gzip已用于静态压缩。

因此，我回到最初的问题，即Content-Encoded缺少static content impression响应标头，但是有证据表明IIS不仅在压缩静态内容，而且还在用gzip压缩它。这仅仅是一个错误吗？这是设计使然吗？

Answer 1

静态压缩将在工作时添加Content-Encoded头。

如果启用了失败的请求跟踪并跟踪静态压缩模块。您将看到此。

这意味着如果不经常点击静态文件，则静态压缩将不起作用。

如果您转发此请求，则延迟时间。然后您将看到该标题。

请注意，压缩文件的最小大小是有限制的。您可以在IIS管理器->服务器节点->配置管理器-> system.webServer / httpCompression-> minfileforcomp

中修改该值