RE: Disappearing Locks

If clients could not 100% rely on the IF header behavior then the locking
mechanism becomes useless because they lose all ability to be sure that a
resource hasn't changed in a way forbidden by their lock.
 
So the answer to your question is that you must always pay attention to the
write lock token and in all cases with no exceptions you must fail the
request if the write lock identified by the token isn't active on the
resource.
 
            Yaron

-----Original Message-----
From: Kevin Wiggen [mailto:wiggs@wiggenout.com]
Sent: Wed, June 16, 1999 10:55 AM
To: w3c-dist-auth@w3.org
Subject: Disappearing Locks



What is the correct implementation for a server under the following
circumstances:
 
A webdav client takes out a lock on a file.  It does a PUT giving the lock
token and the put succeeds.
 
--I am ok with this
 
 
A webdav client takes out a lock on a file.  For some unforseen reason the
lock gets removed (as the spec says it can) and the client does not know
this.  The client then does a PUT sending the lock in the IF header.  The IF
header fails and returns a 412 to the client.....
 
--This is what I think should happen (it is an IF header), but Is this
correct?  Should the IF header fail, or should I let it succeed because the
file is no longer locked and who cares if the client sent extra info.
 
I've gotten in trouble before by saying here is what MS does, but just to
place an example out there :)
 
Office2000 will try to do the PUT, it gets the 412.  It then does a PROPFIND
(at this point it could determine that the file is no longer locked if it
wanted to), then it just trys to do the PUT again sending the lock token.
An endless loop.....
 
Is the idea here to be exact with the IF header logic, or was IF just used
as an easy place to send the locktoken and I should ignore extra locktokens
sent in during requests???
 
Thanks,
Kevin