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

Encodings are supposed to be lossless ... based on my memory of the
discussion and not reading the spec recently, the spirit of ETag and
variants is that an encoding doesn't change the actual underlying entity.
A proxy does need to determine if a cached response will satisfy the
request but it may choose to perform a lossless transform to satisfy the
request or it may forward the request to the origin server. After the
requesting client unravels any encoding, the value will be identical.

On Mon, 23 Oct 2006, Yves Lafon wrote:

>
> On Sun, 22 Oct 2006, Jamie Lokier wrote:
>
> > Consider, for example, a server implementation that does this (this
> > is reasonable):
> >
> >   1. Look at "Accept-Encoding" to decide if known compression methods
> >      are supported as a content-encoding.
> >
> >   2. If compression is supported, then for some types of response,
> >      look at "User-Agent" to check for certain agents that do not
> >      behave correctly for some compressed content types.
> >
> > That server would produce the following two _correct_ responses, for
> > different request headers:
> >
> >   a. Vary: Accept-Encoding
> >
> >   b. Vary: Accept-Encoding, User-Agent
> >      Content-Encoding: gzip
>
> Is it the same server with the same configuration on the same URI ?
> because if it's the case, then only b) is right. The server has the
> knowledge of the variability axis and should populate the Vary: header
> accordingly and not on a case-by-case basis.
> My reading of the spec is that Vary should carry the list of all headers
> used to send compute the variant, so f(x,y), and not send f(5, y) = g(y).
> Cheers,
>
>

Received on Monday, 23 October 2006 17:20:03 UTC