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

Modified on: Thu, 15 Aug 2019 08:40:02 +0800

我们收到一些零星的客户电话(不到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的默认设置复制该问题,但是新版本的鱿鱼似乎工作正常。

作者:,gharper

最佳答案

好的,我想我们已经弄清楚了......

在客户端,Squid 2.5及更早版本不理解“Transfer-encoding:chunked”,因此它将每个chunk作为整个客户端请求提供。由于它只是整个压缩请求的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>

如果有人有更好的解决方案,请告诉我们!

作者:,gharper

相关问答

添加新评论