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

mån 2006-10-23 klockan 15:48 +0200 skrev Yves Lafon:

> Is it the same server with the same configuration on the same URI ? 
> because if it's the case, then only b) is right.

So I and many others say, but not all. And it isn't very clearly
specified either from what I can tell.

> The server has the 
> knowledge of the variability axis and should populate the Vary: header 
> accordingly and not on a case-by-case basis.

That's just the thing. In some configurations the server does not have a
clear knowledge of all the axis the object MAY vary on. All it knows for
certain is the axis THIS variant depends on, which may differ from other
variants of the same URI.

Consider for example combinations of Accept-Language and Accept-Charset.
Many languages does not look for Accept-Charset as their content is only
available in a single charset, but some may have content available in
multiple charset.

My opinion looking at this from the cache perspective is that the server
should in such case respond with "Vary: Accept-Language,
Accept-Charset", but I do buy that server vendors may think differently
not want to examine all possible paths on all requests only to see what
the unified Vary header should look for at the URI, and instead only
wants to add the actual headers the server looked for while processing
the URI. That is Accept-Language, and then only for languages available
in multiple charsets also Accept-Charset.

I have not found anything in the RFC supporting or denying either view.
But I can tell that having caches support vary:ing Vary correctly is
quite complex if one at the same time have to care for performance.

Regards
Henrik