- From: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
- Date: Fri, 9 Dec 2005 13:16:27 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Jim Whitehead <ejw@soe.ucsc.edu>, Lisa Dusseault <lisa@osafoundation.org>, WebDAV <w3c-dist-auth@w3.org>
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. -wsv 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