W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: i22: ETags on PUT responses

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Mon, 07 Jan 2008 00:17:02 +0100
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Werner Baumann <werner.baumann@onlinehome.de>, ietf-http-wg@w3.org
Message-Id: <1199661422.11154.44.camel@hlaptop>

sön 2008-01-06 klockan 14:20 +0100 skrev Julian Reschke:
> Unlikely if the content was rewritten. A server can protect itself from 
> that by generating the strong etag in a manner that guarantees that a 
> range request will fail.

Which is pretty much the same as disabling Range request on the resource
entirely, as returning a different strong ETag on a GET request without
any modifications to the resource would be even more confusing and
damaging.

To be honest this sounds quite much like a actual use-case for weak
etags returned by the PUT and upgraded to strong ETag on GET, if it
wasn't for that odd restriction that weak etags isn't allowed in
If-Match (required to chain PUT/DELETE/... request).

I still maintain that the use of weak ETags should be extended to allow
them in If-Match. The two representations is meant to be equal for all
meaningful purposes, and I don't see why If-Match need to act
differently than If-None-Match. Why would replacing, updating
(properties) or removing a equivalent but possibly not octet equal
resource be handled differently than retreival of the same?

Sorry for coming back to this for some touchy subject of weak etags..
but I do consider them more useful than harmful, if it wasn't for that
If-Match restriction...

Regards
Henrik
Received on Sunday, 6 January 2008 23:18:57 GMT

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