- 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
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 UTC