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

Re: i22: ETags on PUT responses

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 07 Jan 2008 07:56:33 +0100
Message-ID: <4781CD21.5080606@gmx.de>
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 GMT

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