- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 07 Jan 2008 07:56:33 +0100
- To: Henrik Nordström <henrik@henriknordstrom.net>
- CC: Werner Baumann <werner.baumann@onlinehome.de>, ietf-http-wg@w3.org
Henrik Nordström wrote: > 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. Would it? How? > 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). Note they are allowed in "If" headers (RFC4918). > 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? Agreed. > 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... Yes. We need to resolve all these issues (weak vs if-none-match, the matching function, the "requested variant", Etag...) in a coherent way. BR, Julian
Received on Monday, 7 January 2008 06:56:54 UTC