ETags Re: The range of the HTTP dereference function

Larry Masinter wrote:

> # You could argue that the implied contract here is outside the scope of
> # the architecture, but at some point there is a *need* to represent a
> # given resource with a particular set of bits, if only for reification
> # so you can discuss the properties of that representation.
> HTTP uses ETag for this, specifically so that caching can be managed.

But ETags don't really fully solve the problem, do they?  This stems from
the ambiguity in the relationships between resources, representations, and
the bits that one gets back in response to an HTTP request.  ETags interact
badly with things like range requests, compression, delta encoding, etc.
Does the ETag relate to the baf-of-bits received in such a case, or the
potentially reconstructed "snapshot" / representation of resource state that
can be built from several of these things?  Mogul's recent preprint [1] IMO
does a good job both of elaborating the problem and presenting a model and
mechanisms to address it.



Received on Sunday, 31 March 2002 12:59:05 UTC