IIS6 not doing gzip compression when including Via header in request

Question

I have some static content going through a CDN. I am using IIS6's built in compression (gzip & deflate) for static content and this is working fine when I request it. However, when the CDN makes the initial request for the content, it is not being returned compressed. They therefore don't have compressed content to forward to people requesting it. (Yes this raises the issue of people requesting [the zipped] content from the CDN with a browser that can't handle the compression. We'll put that to one side for now, though.)

Here's an example of requesting without the 'Via' header:

HEAD /flash/swfobject.js HTTP/1.1  
User-Agent: curl/7.19.7 (i386-pc-win32)  
Host: localhost:9120  
Accept: */*  
Connection: Keep-Alive  
accept-encoding: gzip  

And it returns a compressed response:

HTTP/1.1 200 OK
Content-Length: 4357
Content-Type: application/x-javascript
Content-Encoding: gzip
Expires: Wed, 01 Jan 2020 00:00:00 GMT
Last-Modified: Wed, 18 Nov 2009 15:36:52 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding
Server: Microsoft-IIS/6.0
Date: Thu, 19 Nov 2009 10:27:50 GMT

However, if I include a 'Via' header in the request (as the CDN does) then the result comes back uncompressed:

Request:

HEAD /flash/swfobject.js HTTP/1.1
User-Agent: curl/7.19.7 (i386-pc-win32)
Host: localhost:9120
Accept: */*
Connection: Keep-Alive
Via: 1.1 204.160.105.17:80 (Footprint 4.5/FPMCP)
accept-encoding: gzip

Response:

HTTP/1.1 200 OK
Content-Length: 14602
Content-Type: application/x-javascript
Expires: Wed, 01 Jan 2020 00:00:00 GMT
Last-Modified: Wed, 18 Nov 2009 15:36:54 GMT
Accept-Ranges: bytes
Server: Microsoft-IIS/6.0
Date: Thu, 19 Nov 2009 10:29:52 GMT

Yes these demos use 'localhost' in the request. I get the same result using the actual domain name from various machines on various networks, though.

Two questions, then:

1. Could this be IIS not applying the compression due to the extra header? and if so, what can I do about it?

2. How can I tell whether the proxy is decompressing the content before returning it?

Bonus question:

3. What can I do to investigate this problem further?

I am aware of SO question 332049, but that has the header in the response, not the request.

Answer 1

A bit late to the party, but I came across this while researching a similar issue so I figured I'd pitch in.

IIS6 does not apply HTTP compression to requests which arrive at the server via an upstream proxy. Since the HTTP 1.1 spec specifies that proxy servers must add a "Via:" header, this must be what IIS uses to distinguish between direct and proxied traffic.

It can be enabled if needed, but I would advise that this is tested first. The claimed reason for this default behaviour is because most proxies do not cope well with compressed content.

References:

TechNet: HcNoCompressionForProxies Metabase Property (IIS 6.0)

HTTP/1.1 Via header field