Re: thinking about etags

On Aug 18, 2007, at 9:05 AM, Larry Masinter wrote:

> I'm confused by the current concept of eTags (now embodied in several
> RFCs and in the discussions, maybe I'm a few years late on this):
>
> The original intent of eTag was that it was a namespace owned by  
> the server
> which corresponded to the content of a response, specifically, the  
> body of
> what the response to a GET would be.

Yes, and then we had a big discussion about variant-id's, and the two
ideas got merged (for good reasons) into what we currently call
entity-tags.  Under the normal case of non-negotiated resource, an
etag and variant-id are identical.  Therefore, methods like PUT were
defined to use If-Match as a conditional on resource state, which
in turn led to its use on other methods in WebDAV because it has no
conception of negotiated resources.

However, we are still left with the notion of variant, and how that
should be defined such that all the places we use it within the spec
can somehow make sense.

> ETag responses for other request methods were "this is what the  
> eTag would
> be
> for the same request (including URI but also other request methods)
> if you used the GET method instead".
>
> In this concept, the client can't make up an eTag because the client
> doesn't own the eTag namespace, and so eTags on request messages  
> (like PUT)
> didn't make sense.
>
> In this concept, you don't talk about the eTag of a 'resource', since
> resources or variants don't have eTags, only the body of a GET  
> response.

No, that's not enough. Bodies do not respond to HTTP requests, and
requests can be conditional on entity-tag, so it is the resource that
carries a set of currently valid entity-tags that happen to correspond
to its current representation(s).  WebDAV makes use of that fact on
its use of conditionals, but everything gets messed up when we talk
about the PROP* methods (which are actually methods on different
resources related to the request-URI).

> Perhaps 2616 didn't really explain this, but I don't really understand
> the current concept of what an eTag really means if it is different
> from the above concept.
>
> Would it help to clarify the eTag description along these lines?
> To not talk about "the eTag of a variant" but "the eTag that would
> be returned in a response to a GET request with the same request
> headers?" (I suppose including a Vary response header).

I am pretty sure we had that discussion several times before, and
yet variant remains in the spec.  I don't remember why at this point.
Maybe just going through and removing the word would be easier.

....Roy

Received on Saturday, 18 August 2007 18:46:44 UTC