我们正在收到一些零星的客户电话（less于我们用户的0.1％）抱怨无法访问我公司的网站 – 他们得到一个空白页面（如果他们使用IE），或“内容编码错误”说该页面使用无效或不支持的压缩forms（如果他们使用FireFox的话）。
目前的怀疑是，当一个HTTP 1.1浏览器请求通过HTTP 1.0代理发送时，我们发回了压缩的HTTP 1.1浏览器请求，这个请求在某种程度上被HTTP 1.0代理所破坏。
该网站是一个Tomcat 4.2.2后端，在IIS服务器上启用了GZIP和DEFLATE的IIS 6.0前端。
有没有人遇到过这种错误？ 有没有一个build议的修复，以避免破坏旧的代理实现？
编辑：我们可以用squid-2.5的默认设置复制这个问题，然而新版本的squid似乎工作得很好。
好的，我想我们已经知道了
在客户端，Squid 2.5和更早版本不理解“Transfer-encoding：chunked”，所以它将每个块作为整个客户端请求传递。 由于它只是整个压缩请求的一个块，所以它是无效数据，不能被浏览器读取。 （不知道这是否是其他代理的问题）
在服务器端，IIS始终发送dynamic压缩的分块编码（因为IIS不caching应用程序响应，所以必须即时压缩每个响应，因此分块编码）。
我们唯一能解决这个问题的方法就是完全禁用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> 如果有人有更好的解决scheme，请让我知道！
如果这是可重现的，那么我将首先检查发送给客户端的响应头，以确保在请求/响应stream中存在一个1.0代理，如Via：响应头中所示。 如果不是的话，那么你有可能是在错误的树上吠叫。 代理服务器必须在请求/响应stream的两个方向插入这个头部和它们使用的协议。