Re: IE vs vary header

On Wed, 19 Jun 2002, Julian Reschke wrote:

> seems that it's an old and well-known issue ([1]) that Internet
> Explorer can't handle Vary headers correctly when passing content
> to external applications. The Apache bug report is from 1999, yet
> unfortunately, even IE 6.0 still has this bug, and according to
> what I hear from Microsoft, *they* don't consider it a bug at all.
> 
> The Apache-recommended workaround is to disable sending the Vary
> header based on the User-Agent header. However, I have my doubts
> that this is a workable solution.
> 
> Consider:
> 
> 1a) Resource X is requested by a non-IE user agent. Server sends
> entity with vary header. Entity and headers are cached by a proxy.
>
> 1b) Same resource is requested by IE. Entity and headers
> (including vary header) are returned by caching proxy.

I am afraid (1b) is incorrect for caches that know about Vary. A
compliant HTTP cache will at least revalidate the cached entity with
the origin server because IE User-Agent header will not match the
cached User-Agent header. A correctly behaving server would then
return a new entity, without the Vary header, and that entity will be
forwarded to IE. To quote RFC 2616:

   When the cache receives a subsequent request whose Request-URI
   specifies one or more cache entries including a Vary header field,
   the cache MUST NOT use such a cache entry to construct a response to
   the new request unless all of the selecting request-headers present
   in the new request match the corresponding stored request-headers in
   the original request.

If a cache does not handle Vary correctly, then (1b) is correct.


In general, I would simply avoid using Vary headers for server-side
negotiation. If you control the server, use other, more robust,
mechanisms to achieve the same goal. I cannot confirm or deny that IE
is broken in this way, but our HTTP compliance testing shows that at
least some popular HTTP/1.1 proxies do not handle Vary correctly.

Alex.

Received on Wednesday, 19 June 2002 11:12:01 UTC