Vary with Care

  • Article

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 https://www.bizcoder.com/the-insanity-of-the-vary-header

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

  • Anonymous
    July 21, 2009
    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="http://wiki.squid-cache.org/KnowledgeBase/VaryNotCaching">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.

  • Anonymous
    July 21, 2009
    @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.

  • Anonymous
    October 18, 2009
    The comment has been removed

  • Anonymous
    October 19, 2009
    @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.

  • Anonymous
    October 19, 2009
    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... Cheers,

  • Anonymous
    March 18, 2010
    The comment has been removed

  • Anonymous
    July 31, 2010
    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?

  • Anonymous
    August 02, 2010
    The comment has been removed

  • Anonymous
    November 23, 2010
    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

  • Anonymous
    November 23, 2010
    @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).

  • Anonymous
    February 28, 2012
    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.

  • Anonymous
    October 25, 2012
    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? ;)

  • Anonymous
    December 27, 2012
    The comment has been removed

  • Anonymous
    December 27, 2012
    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.