IIS 6.0 中的 HTTP 压缩导致某些用户出现问题

Question

我们接到一些零星的客户电话（不到我们用户的 0.1%）抱怨无法访问我公司的网站 - 他们要么得到一个空白页面（如果他们使用 IE），要么“内容编码错误”说页面使用了无效或不受支持的压缩形式（如果他们使用 FireFox）。

当前的怀疑是，当 HTTP 1.1 浏览器请求通过 HTTP 1.0 代理时，我们发送回了压缩的 HTTP 1.1 浏览器请求，该请求不知何故被 HTTP 1.0 代理破坏。

该网站是一个 Tomcat 4.2.2 后端，带有一个 IIS 6.0 前端，在 IIS 服务器上启用了 GZIP 和 DEFLATE。

有没有人遇到过这种错误？是否有推荐的修复程序来避免破坏旧的代理实现？

编辑：我们可以使用默认设置的 squid-2.5 复制该问题，但是较新版本的 squid 似乎工作得很好。

Answer 1

好吧，我想我们已经弄清楚了......

在客户端，Squid 2.5 及更早版本不理解“传输编码：分块”，因此它将每个块作为整个客户端请求传递。由于它只是整个压缩请求的 1 块，因此它是无效数据，浏览器无法读取。（不确定其他代理是否有问题）

在服务器端，IIS 始终发送用于动态压缩的分块编码（由于 IIS 不缓存应用程序响应，因此它必须动态压缩每个响应，因此采用分块编码）。

我们能想到的解决此问题的唯一方法是完全禁用 HTTP 1.0 客户端的压缩，而仅压缩 HTTP 1.1 响应。缺点是，发送 1.0 请求的代理后面的任何人都不会获得压缩数据，并且这些用户的网站加载速度会慢 0.5 - 1 秒。

在 Metabase.xml 文件中进行的更改：

<IIsCompressionSchemes            Location ="/LM/W3SVC/Filters/Compression/Parameters"
...
HcDoOnDemandCompression="TRUE"
HcNoCompressionForHttp10="TRUE"
...
</IIsCompressionSchemes>

如果有人有更好的解决方案，请告诉我！