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

Re: Summary of ETag related issues in RFC2518bis

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 21 Dec 2005 01:32:21 +0100
Message-ID: <43A8A295.8080507@gmx.de>
To: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
CC: Dan Brotsky <dbrotsky@adobe.com>, Jim Whitehead <ejw@soe.ucsc.edu>, WebDav WG <w3c-dist-auth@w3.org>

Wilfredo Sánchez Vega wrote:
> 
>   I don't see how that would help.  For one, I suspect may clients will 
> ask for this all the time, so then why not do it for all clients all the 
> time?  I'm not opposed to giving you the strong ETag, I just don't know 
> how to do it.

You could do it for the case of PUT by pausing for 1 second, right? This 
is exactly why I wouldn't want that to be the default.

>   One possibility is not to return an ETag at all on PUT, nor for GET 
> requests in the first second, and only return the strong ETag once we 
> know what it is.  This eliminates the weak ETag altogether.
> 
>   The advantage here is that while the client would have to poll a few 
> times to get the ETag, it would now when it got the "final" ETag that 
> Jim is advocating for, once it got any ETag at all.  However, for the 
> first second, the file would not be cacheable, which is more or less 
> correct anyway.

That's correct, but how is a client supposed to know that retrying will 
return a strong ETag later? It may talk to a resource that doesn't have 
ETags at all.

Best regards, Julian
Received on Wednesday, 21 December 2005 00:33:52 GMT

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