- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 4 Mar 2003 09:40:37 +0100
- To: "Lisa Dusseault" <lisa@xythos.com>, "'Clemm, Geoff'" <gclemm@rational.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
> 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). 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. > 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. Yes. > 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. > 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). > 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. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 4 March 2003 03:41:14 UTC