Re: Etag-on-write, 2nd attempt (== IETF draft 01)

On Wed, 13 Sep 2006, Lisa Dusseault wrote:

>>>> On Sep 13, 2006, at 24:55, Lisa Dusseault wrote:
>>>>> It's technically correct to say that servers are allowed to rewrite
>>>>> content.  However, existing deployed offline-cache clients assume
>>>>> that they do not.
>> 
>> Well, I have a server that does exactly that, as CVS is expanding keywords 
>> like $Id$ on commit.
>
> And also returns a strong ETag on PUT when making these changes?  Even if so,

Yes, it returns a strong ETag.

> that sounds like one of those cases which, if the client caches the resource 
> entity they PUT, whether that's for viewing now or modification later, will 
> work reasonably well.  Not perfectly -- clients won't have the replacement 
> value for those keywords, which might be nice for the user viewing the 
> resource.
>
> So just how do your clients handle this?  do they have offline caches?

Clients have local caches, but it doesn't really matter, as having the 
modified copy or the original one won't trigger an extra rewrite (ie: the 
cvs version is not changed) in case of a subsequent PUT without any other 
modifications, so per rfc2616,13.3.3, it is indeed a strong validator.

>> Would it be OK for a server to return a 205 Reset Content with the Etag ?
>> That way the client would know that a refetch is in order.
>
> That seems good to me so far.

Of course the issue is already deployed software, but every new way of 
handling this issue won't solve the way they behave.
It would be interesting to get the number of clients implementing 205.

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Wednesday, 13 September 2006 20:08:49 UTC