Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

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!

share|improve this answer
    
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
add comment

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.

share|improve this answer
    
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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.