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

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

From: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
Date: Fri, 9 Dec 2005 13:16:27 -0800
Message-Id: <62FF38E3-0C61-447D-9751-600EA13B4101@wsanchez.net>
Cc: Jim Whitehead <ejw@soe.ucsc.edu>, Lisa Dusseault <lisa@osafoundation.org>, WebDAV <w3c-dist-auth@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

   Right.  I'd change it so that instead of using a weak etag, append  
the string "-potentially-spaztic" or something to the ETag during the  
first second and use the same ETag without the prefix after the first  
second.  Same result as the current implementation, but without  
implying the semantics of a weak ETag.


On Dec 9, 2005, at 1:50 AM, Julian Reschke wrote:

> Wilfredo Sánchez Vega wrote:
>> On Dec 8, 2005, at 12:50 PM, Julian Reschke wrote:
>>> 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.
>>   Why couldn't it?  Just append a suffix or prefix?  What HTTPd does
> But where would it get the suffix from? If it had any way to store  
> it, we wouldn't have the problem in the first place...
>> right now is use the same ETag string but prefixes it with 'W/' to  
>> make it weak.  This accomplishes the goal of making the first- 
>> second etag different, but I think it should do that without  
>> making the tag weak, which implies something that isn't the case.
> It also accomplishes that clients will not be "forced" to sync  
> multiple times within a second.
> Consider a resource that changes 10 times per second, then is  
> stable. A hypothetical client that does conditional GET requests  
> will get an arbitrary version of the resource from within the first  
> second, and then later the stable one. Seems to me that this is a  
> good trade-off somehow.
> Best regards, Julian
Received on Friday, 9 December 2005 21:18:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:34 UTC