W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

Re: FW: ETags again - basic question

From: Elias Sinderson <elias@cse.ucsc.edu>
Date: Mon, 03 Mar 2003 16:46:37 -0800
Message-ID: <3E63F76D.6050607@cse.ucsc.edu>
To: "'WebDAV'" <w3c-dist-auth@w3.org>
Can we include language to this effect in the specification? To do 
otherwise is to invite interop issues. I haven't read the latest draft 
closely, my apologies if you've already inserted the appropriate 
verbiage somewhere. I think this is an important issue that both client 
and server implementers need to understand fully.


Cheers,
Elias



Lisa Dusseault wrote:

>I strongly recommend servers to change Etag only when the entity
>changes. After all, it's the "Entity" tag.  Here are two to three
>practical reasons.
>
>If the ETag changes when the properties change, then:
>1.  Clients who have cached based on the ETag will download the file
>again unnecessarily. Perf problem only.
>2.  Clients who are editing without a lock (including clients who lost
>their lock accidentally due to network conditions) must compare Etag to
>see if it's safe to upload their changes.  This edit will fail and
>confuse the user if somebody else changed the properties and makes their
>upload fail.
>3.  Clients who are editing with a lock might issue a PROPPATCH, then
>try to issue a PUT with an ETag validation. If the ETag has changed due
>to the PROPPATCH, then the client will be very confused whether or not
>the file can be overwritten. The lock still appears to be there, yet the
>ETag changed -- how did that happen?
>
>Geoff's comments are perfectly correct for client implementors -- it's
>hard to predict how servers actually modify ETags. There's no rule
>saying the content is actually different just because the ETag is
>different.
>
>Lisa
>
>  
>
>>-----Original Message-----
>>From: w3c-dist-auth-request@w3.org 
>>[mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff
>>Sent: Sunday, March 02, 2003 5:48 AM
>>To: WebDAV
>>Subject: RE: FW: ETags again - basic question
>>
>>
>>
>>Note that some file-based implementations store the dead 
>>properties as part
>>of the file content and use the file content information to 
>>compute the
>>etag.  So an interoperable client can only make the following 
>>assumptions:
>>
>>- If the resource content changes, the strong etag MUST change.
>>- If the properties change, the strong etag MAY change.
>>
>>Cheers,
>>Geoff 
>>
>>-----Original Message-----
>>From: Jason Crawford [mailto:nn683849@smallcue.com]
>>Sent: Saturday, March 01, 2003 5:15 PM
>>To: Jim Whitehead
>>Cc: WebDAV
>>Subject: Re: FW: ETags again - basic question
>>
>>
>>
>>
>>
>>
>>Okay, I'll take a stab at this one...
>>
>>    
>>
>>>When does an (strong) etag of a resource change?
>>>
>>>1) when the content of a resource has changed (e.g. after a PUT)
>>>2) when one of the properties has changed (e.g. after a PROPPATCH)
>>>3) in both cases 1) and 2)
>>>      
>>>
>>I think the answer is whenever the GET response changes.  So for most
>>resources the answer is almost always (1), not (2) or (3).   
>>If you have a
>>live
>>resource that is dependent on other info, the answer might vary.
>>
>>
>>------------------------------------------
>>Phone: 914-784-7569,   ccjason@us.ibm.com
>>I do not check nn621779@smallcue.com
>>
>>
>>    
>>
>
>  
>
Received on Monday, 3 March 2003 19:46:49 GMT

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