Subject: RE: PUT vs strong ETags

From: "Henrik Frystyk Nielsen" <[email-masked]>
Date: Tue, 29 Nov 2005 21:59:21 -0800

Having a PUT response include an e-tag associated with the current
entity is necessary in order to avoid the lost update problem (see [1]).
I don't think this is a redefinition of the use of e-tags: section
10.2.2 states that

"A 201 response MAY contain an ETag response header field indicating the
current value of the entity tag for the requested variant just created,
see section 14.19."

The use of the term "requested variant" is consistent with the use in
section 14.19 and elsewhere in the spec. It refers to the resource
identified by the request URI regardless of the method used.

Thanks,

Henrik 

[1] http://www.w3.org/1999/04/Editing/

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Mark Baker
> Sent: Tuesday, November 29, 2005 21:00
> To: Scott Lawrence
> Cc: Julian Reschke; HTTP Working Group
> Subject: Re: PUT vs strong ETags
> 
> 
> On 11/29/05, Scott Lawrence <[email-masked]> wrote:
> >
> > On Tue, 2005-11-29 at 11:05 +0100, Julian Reschke wrote:
> >
> > > If a server like this would return an ETag upon PUT, would it
apply
> to
> > > the PUT request body, or the server's internal representation
> returned
> > > in a subsequent GET?
> >
> > I think that the simple rule is that when responding to a PUT, if
the
> > server returns an Etag, then it should be the same value that would
> have
> > been returned in a GET of the resource that immediately followed the
> > PUT.
> 
> My understanding is that an ETag is associated only with the provided
> representation (and the resource whose state it represents); in this
> case the one in the PUT response.  What's suggested above then, would
> seem to be a redefinition of ETag semantics.  But perhaps it's already
> common enough on PUT responses to warrant standardizing despite the
> drawbacks, I don't know.
> 
> I do agree that the "requested variant" language is problematic
though.
> 
> Mark.
> --
> Mark Baker.  Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Coactus; Web-inspired integration strategies   http://www.coactus.com

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Nov 2005 10:12:09 +0100

> current value of the entity tag for the requested variant just created,

Good point, I wasn't aware of that part. But this is for creating 
resources (PUT -> 201), what about updating (PUT -> 200)???

> identified by the request URI regardless of the method used.

Now that's certainly not obvious, and it would be nice if this would 
appear somewhere in the errata.

Best regards, Julian

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 30 Nov 2005 08:18:33 -0500

> appear somewhere in the errata.

Before I add anything to the errata, I ask that specific text be posted
to the WG list and that it gets rough consensus there.

-- 
Scott Lawrence
http://skrb.org/scott/

---

From: Mark Baker <[email-masked]>
Date: Wed, 30 Nov 2005 08:02:56 -0500

> current value of the entity tag for the requested variant just created,

Good find Henrik.  I still think that's suboptimal from the point of
view of providing a *generic* validator which is independent of
response semantics.  If we were addressing the lost update problem
today, I'd be suggesting minting a new response header which could
carry that ETag.

> identified by the request URI regardless of the method used.

I'm with Julian on that being non-obvious.

Cheers,

Mark.