W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

Re: Etag-on-write, draft -04

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 03 Dec 2006 14:41:29 +0100
Message-ID: <4572D409.5010409@gmx.de>
To: Jamie Lokier <jamie@shareable.org>
CC: HTTP Working Group <ietf-http-wg@w3.org>

Jamie Lokier schrieb:
> ...
> I am surprised at the debate, because it seems quite obvious to me
> what a strong Etag is "supposed" to mean as a concept.
> 
> That is: if you have received a strong Etag from the server, it means
> you may use it for conditional and byte-range GET requests in future,
> to confirm the client's stored representation is byte for byte
> accurate.
> 
> That's what it means for everything else.  I don't see why people want
> to give it a different meaning when it's in the response from a PUT.
> 
> (And in case anyone's confused, I think that means I agree with Roy).

Jamie,

the issue is that RFC2616 doesn't clearly define what an ETag means for 
PUT resulting in a status 200.

For 201 Created it *does* say 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.2.2>):

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

IMHO the only way to read this is that you're getting an ETag for what 
the server stored, not what you sent.

So, again, this seems to turn into a discussion about what RFC2616 
*should have been saying*, not what it actually says today.

Now if there's broad agreement that RFC2616 is broken with respect to 
this, let's fix it, potentially breaking some existing servers. But 
let's be clear about that really is a change.

Best regards, Julian
Received on Sunday, 3 December 2006 13:41:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:53 GMT