RE: IE vs vary header

Alex,

thanks for the feedback.

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

Of course you are right -- if and only if "user-agent" is added to the Vary
header. I'd like to avoid that, because that adds yet another dimension. And
even if I do that, the second scenario still can happen, right?

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

What are these other, more robust mechanisms?

Received on Wednesday, 19 June 2002 11:23:47 UTC