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

Julian Reschke wrote:
> >From experience I think it's also worthwhile to further stress the
> >importance of ETag uniqueness among variants of a URI. Very few
> >implementations get this part correct. In fact most major web servers
> >have issues here...
> >
> >Some even strongly believe that entities with different Content-Encoding
> >is the same entity, arguing that since most encoding (at least the
> >standardized ones) can be converted to the same identity encoding so
> >they are in fact the same entity and should have the same strong ETag.
> >
> >Regards
> >Henrik
> 
> I violently agree.
> 
> Could you write up a short description of the problem, for inclusion in 
> the issues list Mark N. is working on?

While on the subject of Etag and variants, it's never been clear what
a Vary header that names a header not in the original request means.

That's the obvious thing for a server to do when it consults a request
header while deciding what entity send, and the header isn't present.
Logically, the sent entity depends on the non-presence of that header
(because if it were present, the calculation on the server would
proceed differently).

For example, a server which sends different entities depending on the
value "Accept-Encoding" would usually send "Vary: Accept-Encoding" in
the response.  But what if the request doesn't have an Accept-Encoding
header?  It seems logical to me that the response should still have
"Vary: Accept-Encoding" to indicate that the response may be different
for requests that have an Accept-Encoding header, but is cacheable for
requests that don't.

But (a) is that use of Vary allowed, (b) is it consistently
interpreted that way by caches, and (c) it would be good for the
improved RFC to clarify this.

RFC 2616 doesn't say anything about variants that depend on
non-existence of request headers, inviting one to read between the
lines and make an assumption about what "same value" means for a
header that's not present.

If that use of Vary is not allowed, or is not interpreted in that way,
it implies a server would have to send "Vary:*" in those cases, which
would be unfortunate overkill as it forces round trips for subsequent
requests.

In my own servers I do set Vary to the names of all request headers
consulted in calculating the response, including those not present.
But I haven't tested the behaviour of caches, so this might be a mistake.

-- Jamie

Received on Thursday, 19 October 2006 22:31:03 UTC