RE: Interop issue: Proposal for fixing lock token provision

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