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.

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 if 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.

share|improve this question
    
As I stated here: stackoverflow.com/questions/1769694/… Could the Via header be turning off compression in IIS6? Since via indicates a proxy request, IIS might just be letting the proxy deal with the actual end user compression. Obviously not ideal, but could be the explanation. –  Christopher_G_Lewis Nov 24 '09 at 5:35
    
Eventually gave up on this. Couldn't find a way of determining if what IIS6 does with/because of the Via header. The general response from asking this elsewhere was upgrade to IIS7. –  Matt Lacey Dec 4 '09 at 15:04

1 Answer 1

up vote 1 down vote accepted

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

share|improve this answer

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.