- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: 2002年2月25日 09:58:21 +0100
- To: "Clemm, Geoff" <gclemm@rational.com>
- Cc: w3c-dist-auth@w3.org
- Message-Id: <D1D865AB-29CD-11D6-BF5C-00039384827E@greenbytes.de>
Am Sonntag den, 24. Februar 2002, um 00:53, schrieb Clemm, Geoff: > The paragraph referred to was in section 9.8: > > The timeout counter SHOULD be restarted any time an owner of > the lock > sends a method to any member of the lock, including unsupported > methods, or methods which are unsuccessful. However the lock > MUST be > refreshed if a refresh LOCK method is successfully received. > > Unfortunately, I cannot remember the rationale for removing this > paragraph, although it might have been that servers aren't actually > doing this in practice? There were several issues in this: 1. unsupported methods might not even be seen by the WebDAV server application (or recognized as WebDAV methods). 2. Refreshing locks on PROPFIND by _any_ client (PROPFIND does not check on If: headers) will give unpredictable timeout behavior. Checking with PROPFIND if a lock is still there has counterproductive side effects. That's the, most likely incomplete, list I remember. //Stefan > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:ccjason@us.ibm.com] > Sent: Monday, February 18, 2002 7:01 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: IETF meeting: Refreshing locks > > > > What does the following text from the SLC IETF meaning mean? > >> Refreshing Locks.... >> >> Consensus was to delete paragraph on lock refresh. >> Eric - clients seem to be expecting locks to hang around, when they > expire it causes problems. > > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > >
Received on Monday, 25 February 2002 03:58:38 UTC