Vary with Care

About the Vary Response Header 

As described in the HTTP/1.1 specification (RFC2616), the Vary response header allows a cache to determine if a cached (still fresh) response may be returned for a subsequent request, based on whether or not the new request's headers match those that were sent when the the previously response was originally cached.

  The Vary field value indicates the set of request-header fields that
  fully determines, while the response is fresh, whether a cache is
  permitted to use the response to reply to a subsequent request
  without revalidation. For uncacheable or stale responses, the Vary
  field value advises the user agent about the criteria that were used
  to select the representation.

The Problem(s)

Unfortunately, the WinINET caching engine (below Internet Explorer and other applications) does not cache outbound request headers.  This limitation makes it impossible for WinINET to perform the request-header matching algorithm. 

Hence, Internet Explorer is conservative and generally will refuse to return a cached Vary response for a new request, except under special circumstances, as detailed below.

Note: IE's isn't the only cache with issues around Vary; see

Internet Explorer 6

Internet Explorer 6 will treat an uncompressed response with a Vary header as completely uncacheable, unless the Vary header contains only the token User-Agent.  Hence, a subsequent request will be made unconditionally, resulting in a full re-delivery of the unchanged response. This results in a significant performance problem when Internet Explorer 6 encounters Vary headers.

Note: IE6 will ignore the Vary header entirely if the response was delivered with HTTP Compression; the header is dropped when URLMon decompresses the cache file on WinINET's behalf. This problem was fixed in IE7 as decompression was moved down into WinINET.

Internet Explorer 7

For Internet Explorer 7, the problem was not eliminated, but its impact was mitigated in some common cases. 

When evaluating a cached response that has a Vary, IE7 can make a conditional request (e.g. If-Modified-Since) rather than an unconditional request.

In order to take advantage of this improvement, the original response must contain an ETag.

Even though revalidation of cache response will require one round trip to server, it is still a significant improvement if server responds with a HTTP/304, because the response body is not transmitted.

Note, WinINET will remove the Vary: Accept-Encoding header if it decompressed the response.  Therefore, you should only send a Vary: Accept-Encoding header when you have compressed the content (e.g. Content-Encoding: gzip). 7.21.2009: see the comments below for a caveat on this.

Best Practices

  • Never send Vary: Host.  All responses implicitly vary by hostname, because the hostname is a part of the URI, and all requests vary by URI.
  • Only send a Vary: Accept-Encoding header when you have compressed the content (e.g. Content-Encoding: gzip).

7/14/2010 Update: Improved in IE9; IE9 will ignore Vary: Accept-Encoding, Vary: Host, and Vary: User-Agent, or any combination of these. You should still send an ETAG if you cannot avoid using VARY responses.

Comments (14)
  1. Steve Clay says:

    In a response, Vary indicates content negotiation is occurring, so "Vary: Accept-Encoding" should be sent even when the non-encoded version is sent.

    If you don’t, proxies may end up caching only the non-encoded version. <a href="">Squid does this</a>.

    What I haven’t figured out is what to do about IE6 without the "SV1" in the UA. You can’t reliably send gzipped JS to it, but if you leave off Vary and the request passes through a proxy, you’ve eliminated the ability of the cache to store the gzipped version.

  2. EricLaw [MSFT] says:

    @Steve Clay: From a protocol-perspective, of course you are correct. The point of this post is to explicitly state that using Vary: Accept-Encoding on uncompressed responses hurts performance in the most popular user-agents.

    Squid could work around their limitation in the most common case (e.g. don’t blindly delete compressed, cached variants that are still fresh).

    An IE6 user who is current on patches should be able to properly decompress any response — XPSP2 (identified by the SV1) shouldn’t be required. In contrast, an IE6 user who is not current on patches has probably already been pwned by the bad guys.

  3. Eric,

    I’m starting to think that IE6’s behaviour is preferable to IE7’s.

    Since it (presumably) controls the UA and AE headers, and doesn’t allow their modification (using XHR, etc.), IE6 can safely strip Vary: UA and AE, and treat those responses as fresh. IE7, OTOH, forces revalidation on these responses.

    Why not combine the behaviours and force revalidation on anything with a Vary that’s *not* AE or UA? That seems like the most performance and safest thing you can do without remembering request headers…

    Also, I don’t think it’s as easy as you say for Squid to correct their behavour; there’s no simple way for them to differentiate between a server that doesn’t set correct headers and one that has stopped supporting compression.


  4. EricLaw [MSFT] says:

    @Mark: IIRC, IE7 & IE8 also ignore the Vary: User-Agent directive.

    It’s also important to recall that IE6 doesn’t simply revalidate Vary’ing responses; it doesn’t cache them at all.

  5. Hi Eric,

    Right, but IE6 will cache something that varies on AE or UA, right? Do 7 and 8 also ignore Vary: Accept-Encoding? If so, this isn’t a big problem in the common(est) case…


  6. EricLaw [MSFT] says:

    @Mark: No, IE7 and IE8 will not ignore "Vary: Accept-Encoding" **unless** the response had a non-identity "Content-Encoding" (aka "if it was compressed"). Hence, if you send a Vary: Accept-Encoding header without compressing your content, it hurts performance in IE7/IE8.

    @Richard: The first IE9 Developer preview behaves the same way as IE8 in this regard.

  7. Dan Zollman says:

    I've got a question as someone who's still learning how HTTP caching works. Let's say a resource is set up as follows:

    – Normally, send "Vary: Accept-Encoding, User-agent"

    – If client is IE8 or earlier, and if content is not compressed, don't send the vary header, but send "Cache-Control: private"

    Wouldn't that prevent proxies from storing the uncompressed version?

    And, a separate question: if we're talking about a gzipped page, and if IE supports gzip anyway, why would uncompressed content be sent to IE (with the Vary header) in the first place?

  8. EricLaw [MSFT] says:

    @Dan: Yes, Cache-Control: private tells a (shared) proxy not to cache the resource.  

    Just because the client requests GZIP'd content doesn't mean that the server must give it back (for instance, many sites send the first response without compression and spin up a background thread to compress the content and cache it on the server for later use). Additionally, just because IE supports compressed content doesn't mean that it will always ask for it– users can disable compression, or edge proxies may strip the client request's Accept-Encoding header.

  9. Vincent Voyer says:

    I have request being cached even if vary host is set.

    IE6 will send "if modified since" even if vary host is set, is this because I also have cache control max age public set ? Thanks

  10. @Vincent: I suspect you're seeing this behavior because perhaps your response is compressed. As noted, IE6 entirely ignores Vary if compression is used. That's the only explanation I see. (I-M-S and If-None-Match will be sent for an expired cached response, or in IE7+ if a response requires validation due to Vary).

  11. Steve says:

    Eric, Is it fair to presume that in most cases… a web server that is serving up content with Expires and Cache-Control headers to explicitly cache static resources (CSS/JS/GIF/JPG/PNG) and not cache HTML pages should not need to send a Vary header… ever?

    e.g. if the server passes the correct headers for caching… can we ditch the Vary header completely?

    EricLaw: @Steve: The idea behind Vary is that the same URL may yield a different resource based on some factor in the headers. For instance, if I had a "Buy" PNG file, I could use VARY: Accept-Language and return a localized PNG file for a localized page. In practice, of course, sites will typically use a different URL for this purpose, because support for Vary is sporadic and causes cache bloat problems for shared caches.

  12. Mark Nottingham says:

    Just a note – your "best practice":


    Only send a Vary: Accept-Encoding header when you have compressed the content (e.g. Content-Encoding: gzip).


    Will make pretty much every intermediary cache thrash, and violates HTTP. Anybody left at MSFT who can fix this? 😉

  13. @Mark: No one at Microsoft updates IE6-9's functionality, if that's what you're asking; only security patches are issued. I'm afraid I don't understand your claim of "intermediary cache thrash"– it would be interesting to have a fuller explanation of the problem you think would arise. It would also be interesting for you to be more explicit about where, exactly in RFC2616 requires "Vary" as real-world practice suggests that it's insufficiently plain.

  14. In particular, it should be noted that, in virtually all cases I can think of, it would be preferable for the client to retrieve a locally cached albeit decompressed response in preference to a remote retrieval of a compressed version of the resource.

Comments are closed.

Skip to main content