- From: Yves Lafon <ylafon@w3.org>
- Date: Thu, 23 Aug 2007 10:12:32 -0400 (EDT)
- To: Larry Masinter <LMM@acm.org>
- Cc: ietf-http-wg@w3.org
On Sat, 18 Aug 2007, 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.
[..]
> 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.
"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
Received on Thursday, 23 August 2007 14:12:38 UTC