- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 19 Jun 2002 17:23:14 +0200
- To: "Alex Rousskov" <rousskov@measurement-factory.com>
- Cc: <ietf-http-wg@w3.org>
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