- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Tue, 29 Nov 2005 21:59:21 -0800
- To: "Mark Baker" <distobj@acm.org>, "Scott Lawrence" <scott@skrb.org>
- Cc: "Julian Reschke" <julian.reschke@gmx.de>, "HTTP Working Group" <ietf-http-wg@w3.org>
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: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org] > 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 <scott@skrb.org> 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
Received on Wednesday, 30 November 2005 05:59:28 UTC