[200 OK]: A Port80 Software Blog

We're all 200 OK: Web, HTTP and IIS Insights
posts - 199, comments - 719, trackbacks - 95

The Vary header and HTTP Compression

As an httpZip or ZipEnable evaluator you may have noticed that compressed responses are returned with the Vary: Accept-Encoding header. In a nutshell, here’s why it’s there…

Say you have a proxy server that is caching your responses. It could be yours or it could be one that your visitors are connecting through. This proxy is doing its job of off-loading connections to your web server and quickly serving cacheable files to your users. Everything's going fine.

Now say you've decided to add a compression module to your web server to compress your outgoing files. This is even better. You're compressing and caching your outbound files whenever you can. What's the problem here? Well, it's that you've introduced a situation where a form of content negotiation needs to take place to prevent problems from occurring.

Consider what happens when a user makes a request for a file that is cached on one of these proxy servers with a user agent that does not support decompression. How is the proxy to determine whether it has a suitable file to send? It is likely to end up with both a compressed and an uncompressed version of the file. What is needed is a way to distinguish between two versions of the same file.

Here's where the VARY header comes in.

Acceptable parameters for the Vary header include the HTTP headers from the request that must be used in negotiating which file is suitable for sending. For example, when httpZip sends a Vary: Accept-Encoding header with a compressed response, this tells the proxy that if it caches the file, it must only return that file to a user agent with the same Accept-encoding request header value as the original requester. Problem solved. Simply and elegantly. That's it in a nutshell.

Of course, in reality it was a lot more like a sausage than a nut. There was a lot of debate about whether and how the Vary header was suitable for handling the content negotiation in the case of HTTP compression. There are some serious limitations in the way the Vary header is supposed to work. They are much more obvious in cases of content negotiation based on things like language preferences when q-ratings are introduced. But that’s a different case with its own set of raging debates.

posted on Friday, January 21, 2005 6:33 PM

Feedback

# re: The Vary header and HTTP Compression

Internet Explorer versions 4 through 6 all have a bug in dealing with the Vary header.

For versions 5 through 6, if the Vary header is set and its value is anything other than "Vary: User Agent", it will not cache the file if the file was served uncompressed to the browser - assuming the file is served with the correct headers to allow browsers/proxies to cache the content.

For version 4.x, it's worse in that setting any Vary header whatsoever will cause the browser not to cache any content.
12/7/2005 10:36 AM | Tom Kagan

# [JRA-9461] Increase the scope of the gzip compression to include JS and CSS files

We now exlude MSIE 4-6 from all CSS and javascript compression, and Netscape 4 from all compression (including HTML). However, we allow Firefox, Opera and IE 7. This makes a *huge* difference when downloading css and javascript!

Unfortunately it ...
9/8/2007 5:13 PM | JIRA: JIRA

# re: The Vary header and HTTP Compression

thanks nice text
4/7/2008 7:45 AM | software

Post Comment

Title:  
Name:  
Url:  
Comment:  
Verify:
(Enter the word as it appears in the box above.)