- From: Lisa Dusseault <lisa@xythos.com>
- Date: Tue, 4 Mar 2003 12:28:43 -0800
- To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Clemm, Geoff'" <gclemm@rational.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
Comments inline > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, March 04, 2003 12:41 AM > To: Lisa Dusseault; 'Clemm, Geoff'; 'WebDAV' > Subject: RE: FW: ETags again - basic question > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Tuesday, March 04, 2003 1:24 AM > > To: 'Clemm, Geoff'; 'WebDAV' > > Subject: RE: FW: ETags again - basic question > > > > > > > > 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. > > And I object again :-) > > This is yet another issue where theory and reality > (implementation practice) > collide. As Geoff noted, there are servers that store > properties in the same > file entitiy, and thus both DAV:getlastmodified and > DAV:getetag change when > dead properties change. Furthermore, there are servers that actually > *modify* the entity contents upon PROPPATCH (I've seen IIS do this for > Office files). I absolutely agree with you, or rather, you agree with me, because that's what I meant. Servers that modify the entity (even due to property changes from PROPPATCH) should change the Etag :) > All of these behaviours may be surprising, but > *do* conform > to RFC2518 and RFC2616, and I don't think we can forbid them > without taking > away a lot of implementation freedom. It is within the rules of 2616 to change the Etag when the entity does not change. However, it is not expected behavior and causes interoperability problems (screws the user if they're making changes). Since WebDAV adds properties to resources, we need to explain how properties affect Etags and how Etags are used in a distributed authoring environment. So anyway, we agree with each other again -- we can't forbid servers to change an Etag when the entity doesn't change. All the spec can do is recommend with SHOULD. > > 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. > > So they'd better take a lock as well. Right, but there are several cases where a very responsible locking client might not have a lock at the point where the user wants to do a PUT. 1. The server doesn't support locks. 2. The user decided to open the file for reading only. Maybe somebody else had a lock initially, or the user didn't expect to go make changes, or the user didn't have permissions to write when the first did the GET and started editing. Later, when the user instructs the client to save changes, the client should be perfectly capable of seeing whether the entity changed since the GET request -- using the Entity Tag. 3. The client very responsibly got the lock, for a responsible period like 1 hour. The client refreshed the lock as required, until the user unplugged and walked onto the train with their laptop (hey, I do this every night). On the train, the user finally saves their changes. Now the client has a set of changes but no lock. When the client gets a network connection again, what does the client do? It needs to do a PUT with an If-Match header and an Etag. (a) If the Etag matches, then the client can synchronize the offline changes. (b) If the Etag doesn't match because the entity changed, the client has to find some way to error and ask the user what to do. (c) If the Etag doesn't match even though the entity has NOT changed, the client either has to download the entire entity again and compare for a literal match, or the client can screw the user by telling them the resource body changed when in fact it didn't. Yuck. > > > 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? > > That's indeed a problem. I think the correct way to handle > this would be to > optionally return a new entity tag after PROPPATCH (just like > PUT is doing > it). Unless this were part of the spec, I'm not sure clients would notice an Etag on a PROPPATCH response. Otherwise, that's a good idea. This list has discussed in the past defining a new calculated property to allow the client to tell when dead or unprotected properties have changed -- a Property Tag or PTag, perhaps. Has the day come for that idea? Lisa
Received on Tuesday, 4 March 2003 15:28:44 UTC