- From: Elias Sinderson <elias@cse.ucsc.edu>
- Date: Mon, 03 Mar 2003 16:46:37 -0800
- To: "'WebDAV'" <w3c-dist-auth@w3.org>
- Message-ID: <3E63F76D.6050607@cse.ucsc.edu>
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 UTC