Subject: thinking about etags

From: "Larry Masinter" <[email-masked]>
Date: Sat, 18 Aug 2007 09:05:21 -0700

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.

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.

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).

Larry

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 18 Aug 2007 11:46:36 -0700

> 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.

> resources or variants don't have eTags, only the body of a GET  

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).

> 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

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 23 Aug 2007 01:07:11 +0200

> if you used the GET method instead".  

That's not the full picture. There is exceptions like 201 responses
where the ETag is not necessarily related to the requested resource.

Example: POST creating a new resource and returning a 201 with the
Location of the created resource and it's ETag.

There may be other odd cases as well..

Regards
Henrik

---

From: Yves Lafon <[email-masked]>
Date: Thu, 23 Aug 2007 10:12:32 -0400 (EDT)

> what the response to a GET would be.

[..]

> resources or variants don't have eTags, only the body of a GET response.

"Entity Tag" refers to the entity, so in that case the body of the 
response, as you say. However, it is also intuitive to see it linked to 
the request, and in the case of a representation, to the Content-Location 
URI (when present), as the value of CL defines the base URI of the entity.

When you are editing things using ETags validators to do optimistic 
concurrent editing, having the ETag associated with the "real" URI of the 
entity served is definitely a win, as you don't have to do a HEAD on the 
value of CL to get the "real" ETag before doing a PUT on the CL URI . 
(Note that it requires that representation are as often as possible 
served with CL, which is almost never done)

Unfortunately it's not the case in the definition of ETags, unless 
something like structured etags [1] are used (and it requires the 
knowledge of them by the client). 
(Which reminds me... should 2295 be on the radar?)

> Would it help to clarify the eTag description along these lines?

Definitely.
Cheers,

[1] http://www.ietf.org/rfc/rfc2295.txt

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 27 Aug 2007 11:15:42 +0200

On sön, 2007-08-26 at 14:12 -0700, Larry Masinter wrote:

> I suppose you're right. Mainly, though, the point is that the eTag
> corresponds to the entity and not to the resource;

Yes. But the distinction between resource and entity is a bit muddled,
and are often used interchangeably, which works fine for GET requests on
non-varying resources but not otherwise.

my understanding:

An entity is the HTTP representation of a resource or it's result.

A resouce is a server-side representation or data processor, preferably
identified by a unique URI.

ETag ends up somewhere between the two.. but yes, it's more related to
the HTTP entity than the resource.

Probably the main source to the confusion is that HTTP servers have
evolved and today often work in manners which wasn't really considered
when the RFC was written, adding a lot more dynamics to the process. And
additionally the HTTP object and cache model is not well understood by
most which makes it hard for them to correctly place the ETag relation.

I still often find people who insists that the ETag for two response
entities from the same resource, differing only in the content-encoding
should be the same, as they are generated from the same resource and
both represents the same..

> I guess it was in the discussion about PATCH where people were getting
> confused. I thought it was interesting that ICAP defined "ISTag"
> just to have a way of talking about resource state rather than
> entity state.

Well.. ICAP doesn't really have resources in the same sense as HTTP, and
ETag would not fit. It's cache model is very different with the cache
being defined by the encapsulated protocol rather than ICAP itself..

The equalence in HTTP would be caching of a protocol carried over HTTP
POST requests or similar, where the request-URI only identifies the
processing resource. (i.e. XMLRPC). And there ISTag would be a good fit.
Additionally ISTag is not a validator, just an informational response
tag.

I suppose it could fit for WEBDAV as well, but don't understand the
fineprint of WEBDAT well enough to say if it fits well or not.. but I
guess not as WEBDAV is .. well.. different.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Aug 2007 13:48:48 +0200

Henrik Nordstrom wrote:
> ...
> ...

The only difference in WebDAV is that PROPFIND and PROPPATCH essentially 
add a second set of resources that share the same URIs as the "GETtable" 
content.

As long as the definition of "requested variant" solely depends on the 
request headers, this is not an issue, except that you really can't use 
ETags as cache validators for properties.

*Changing* "requested variant" to include method name and request body 
solves that issue, but IMHO causes lots of new problems.

Best regards, Julian