6

We're getting a few sporadic customer calls (less than 0.1% of our users) complaining of not being able to access my company's website - either they get a blank page (if they use IE), or a "Content Encoding Error" that says the page uses an invalid or unsupported form of compression (if they use FireFox).

The current suspicion is that when an HTTP 1.1 browser request comes through an HTTP 1.0 proxy, we're sending back the compressed HTTP 1.1 browser request, which is somehow being mangled by the HTTP 1.0 proxy.

The website is a Tomcat 4.2.2 back end with an IIS 6.0 front end with GZIP and DEFLATE enabled on the IIS servers.

Has anyone encountered this sort of error before? Is there a recommended fix to avoid breaking older proxy implementations?

Edit: We can replicate the issue with a default setup of squid-2.5, however newer versions of squid seem to work just fine.

gharper
  • 5,365
  • 4
  • 28
  • 34

2 Answers2

4

Ok, I think we've figured it out...

On the client side, Squid 2.5 and earlier doesn't understand "Transfer-encoding: chunked", so it delivers each chunk as the entire client request. Since it's only 1 chunk of the entire compressed request, it's invalid data and can't be read by the browser. (Not sure if this is an issue with other proxies)

On the server side, IIS always sends chunked encoding for Dynamic Compression (since IIS doesn't cache application responses, it has to compress each response on the fly, hence the chunked encoding).

The only way we can think of to fix this is to completely disable compression for HTTP 1.0 clients and only compress for HTTP 1.1 responses. The drawback is that anyone behind a proxy that sends 1.0 requests won't get compressed data and the site will load 0.5 - 1 second slower for those users.

Changes made in the metabase.xml file:

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

If anyone has a better solution, please let me know!

gharper
  • 5,365
  • 4
  • 28
  • 34
  • phew, this thing bothered me for two months, finally got it solved using this solution... thank you very much!!! – zappan Apr 15 '10 at 14:56
1

If this is reproducible then I would start by examining the response headers sent to the client to ensure that there is a 1.0 proxy somewhere in the request/response stream as indicated in the Via: response header. If not, then chances are you're barking up the wrong tree. Proxies must insert this header and the protocol they use in both directions of the request/response stream.

squillman
  • 37,618
  • 10
  • 90
  • 145
  • Yup, it's reproducible and all of the customers that I'm aware of have been behind a proxy (surfing from a hotel seems to be the most common situation, followed by workplaces)... We can replicate the error using squid, but we're trying to understand the exact reason why this breaks and to figure out what should be done to fix it. – gharper May 27 '09 at 15:48