- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 4 Mar 2003 22:24:37 +0100
- To: "Lisa Dusseault" <lisa@xythos.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'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 9:29 PM > To: 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV' > Subject: RE: FW: ETags again - basic question > > ... > > 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. Agreed. > > > 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. So we may want to add this to RFC2518bis (if a PROPPATCH modifies the etag, it SHOULD be returned in a PROPPATCH response). > 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? I always liked that for symmetry reasons. But how does this help with the original problem? Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Tuesday, 4 March 2003 16:25:11 UTC