- From: Lisa Dusseault <lisa@xythos.com>
- Date: Mon, 16 Sep 2002 13:46:50 -0700
- To: "'Jason Crawford'" <nn683849@smallcue.com>
- Cc: "'Webdav WG'" <w3c-dist-auth@w3c.org>
The original WebDAV plan for locks was that the client would LOCK the resource, then GET, then issue PUT. The client only wants this PUT request to succeed if the lock was still there. This avoids the lost update problem if the lock disappeared somehow and the resource was changed in between the GET and the PUT. This goal can be accomplished by putting the lock token in an IF header. That's why we need to keep the existing behaviour, which is reflected in goal #1 which you quoted. (Note that this is necessary for those servers that do not support ETags even though they MUST) However, an even better approach is for the client to LOCK the resource, then GET (note the ETag), then issue a PUT with the ETag in the If-Match header. This way, the request is really testing directly to see if the resource has changed, rather than whether the lock is still there. The request can succeed if the lock is gone away, as long as the resource has not been updated. This scenario is met by goal #2 (not quoted) lisa > -----Original Message----- > From: Jason Crawford [mailto:nn683849@smallcue.com] > Sent: Sunday, September 15, 2002 6:55 PM > To: Lisa Dusseault > Cc: 'Webdav WG' > Subject: Re: Interop issue: Proposal for fixing lock token provision > > > > > > 1. Clients should be able to provide lock tokens in conditional requests > > that cause the request to fail if the token does not still match the > > state. This goal is currently met by the If header, but this goal must > > continue to be met by any new solution. > > Could someone say more about this. An example of why a client might > want this would complete the picture. > > > ------------------------------------------ > Phone: 914-784-7569
Received on Monday, 16 September 2002 16:48:35 UTC