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

Re: Summary of ETag related issues in RFC2518bis

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Tue, 20 Dec 2005 14:06:27 -0800
Message-Id: <c03b79139472bf08f703439c7b6efe16@osafoundation.org>
Cc: Julian Reschke <julian.reschke@gmx.de>, Dan Brotsky <dbrotsky@adobe.com>, Jim Whitehead <ejw@soe.ucsc.edu>, WebDav WG <w3c-dist-auth@w3.org>
To: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>

Perhaps Content-MD5 would help solve a number of these issues in a much 
cleaner way.  It doesn't do away with ETags I suspect, but can help 
with PUT equivalence.

Lisa

On Dec 20, 2005, at 1:54 PM, 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.
>
>   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.
>
> 	-wsv
>
>
> On Dec 20, 2005, at 12:46 AM, Julian Reschke wrote:
>
>> But it seems that there's a simple way to fix this (for Apache): 
>> should a client require a strong ETag upon PUT, it could make that 
>> explicit in the request (new header?), so that the server can just 
>> special-case this, and do what's needed to ensure the ETag is stable. 
>> Wilfredo?
>
>
Received on Tuesday, 20 December 2005 22:06:36 GMT

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