W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: [Fwd: Re: PUT vs strong ETags]

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 08 Dec 2005 21:50:24 +0100
Message-ID: <43989C90.6070103@gmx.de>
To: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
CC: Jim Whitehead <ejw@soe.ucsc.edu>, Lisa Dusseault <lisa@osafoundation.org>, WebDAV <w3c-dist-auth@w3.org>

Wilfredo Sánchez Vega wrote:
> ...
>   Yes, but it would also be achieved if a strong ETag was delivered 
> during the first second (including on PUT).  Use of a weak ETag doesn't 
> help with that, as far as I can tell.

But with the current algorithm, the server can't return a strong ETag, 
unless it blocks updates of that content for one second. That may be 
unacceptable for some resources.

> ...
>> I think I disagree here. A few days ago I asked about this on the HTTP 
>> mailing list, and the consensus seems to be:
>>
>> - just because a server accepts a PUT and returns a (strong) ETag 
>> doesn't mean that it didn't rewrite the contents
>>
>> - the ETag is *not* for the entity body returned with PUT, but for the 
>> entity you would get upon a subsequent GET/HEAD
>>
>> - and yes, RFC2616 needs to be clarified
>>
>> (see thread 
>> <http://lists.w3.org/Archives/Public/ietf-http-wg/2005OctDec/thread.html#13>) 
>>
> 
>   Consensus on that thread seems to be that a ETag on PUT should be the 
> ETag you'd get on a subsequent GET.  I don't see any discussion about 
> strong vs. weak and whether changing from strong to weak and back is a 
> good idea, which is, I think the point that Jim was making.

Yes, that question wasn't asked over there.

>>>   OK, that's a vote for "the weak etag is wrong".
>>
>> My take is that the current drafts requirements for strong ETags and 
>> for ETags returned upon PUT are questionable. I think it has been 
>> demonstrated that
>>
>> 1) in some cases, weak ETags are just fine, and that
>>
>> 2) a requirement to return an ETag upon PUT will *need* to also 
>> clarify what that means
>>
>> The latter optimally would be an erratum to RFC2616, which well 
>> require a discussion over on the HTTP mailing list, with proposed text 
>> changes and consensus among the readers of the list (I'm *not* 
>> volunteering to do this because of other priorities).
> 
>   I'm not sure why you think the requirements for strong ETags in the 
> current HTTP spec is a problem.  I agree that clarification on the 

I was talking about the current version of RFC2518bis...

Best regards, Julian
Received on Thursday, 8 December 2005 20:52:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:11 GMT