Re: ETags vs Variants, was: Revising RFC2616 - what's happening

sön 2006-10-22 klockan 04:35 +0100 skrev Jamie Lokier:

> > I would say that if the value for "Vary" changes between to HTTP 
> > requests, the sever implementation/configuration has somehow changed, 
> > and a proxy should invalidate all cached entries for that URI.
> 
> No, no.

Yes yes yes ;-)

> The natural implementation is for the server to note each time a
> request header is examined to compute the response, and to emit Vary
> with those headers.

True, but this creates quite a bit of a nightmare at the cache level. So
with this requirement Vary: will still become equal to "no-store" in
most implementations, perhaps with hardcoded special cases for the most
common uses or more likely caches trying to outguess the servers and
implementing their own content negotiation schemes. This simply because
general caching of Vary entities then becomes too complicated to even
care trying to index the variants in the cache.

> If you specify that a cache must purge all variants when receiving a
> Vary header which is different from previously received Vary, then
> servers will realistically have to send "Vary: Accept-Encoding,
> User-Agent" even in the case that the response _doesn't_ depend on
> User-Agent.

Which is fine to me. Especially if the server supports ETag and
If-None-Match on larger responses.

> However, when the server's use of request headers is less tightly
> coupled, it's _much_ harder to do that.

True.

So question then becomes multifold:

1) Is caching of Vary responses worth the effort to get it working
proper?

2) If caching of Vary is desireable, what component of the network
should have to deal with the complexity involved?

  * The servers, where more complex servers will have a harder job
determining a proper Vary header.

  * Every cache implementation needing to have support for the most
complex cases.

What we see today is that neither component really cares. Most servers
forgets to send Vary headers when they should, instead using no-cache to
solve the problem. And most caches sees Vary too complex and reads it
the same as no-store, or in some user-agent cases reads Vary wrongly as
"no-cache" (need to revalidate on every request) and additionally
getting the validation completely wrong.

Regards
Henrik