Locking questions

I have some detailed questions about locking as described in version 08 of the
WebDAV spec. Any help would be greatly appreciated.

Section 5.1: is there any intent for lock scope to apply across lock types? For
example, if a server supported read locks, could a user take out an exclusive
write lock on a resource that is read locked by another user? Or are the
semantics across lock types dependent on the lock type and defined by the
server? If so, how could these semantics be discovered through a supportedlock
property?

Section 7.10.1, last sentence says: "The response MUST contain the value of the
lockdiscovery property in a prop XML element". What exactly is in the
lockdiscovery property returned on a successful LOCK? Is it the activelock just
granted, or the same activelocks that would be returned by a lockdiscovery
PROPFIND? If it is the latter, how would an application determine which lock
token was just granted to the user? The owner element in the lockdiscovery is
not sufficient because it does not necessarily indicate the credentials of the
owner of the lock but rather gives contact information suitable for human
interpretation. If it is the former, then there's no problem as there is
exactly one locktoken in the lockdiscovery for a successful LOCK, and it's the
one just granted.

In a follow-up question to the above, how would an application programatically
determine the credentials (the user id from the Authorization header using the
Basic or Digest authorization scheme)? A lockdiscovery PROPFIND will return the
owner, but this isn't necessarily the authorization credentials? Is it intended
to hide this information? If so, then applications are responsible for
retaining locktokens for all resources they have locked until they no longer
need them. For example, if an application obtained an exclusive write lock on a
resource with infinite time-out, and subsequently lost the locktoken, there
would be no way for the owner to unlock the resource without becoming the admin
user.

Section 6.5 describes the problem of race conditions resulting from multiple
concurrent processes acting under the same principal on the same resources. I
do not understand why requiring locktokens for all resources modified by a
method solves this problem. I assume a scenario like the following would be
typical: Program A takes out a lock on Resource A for User A, and retains the
lock token returned by the LOCK method. At some subsequent point it time,
Program A communicates the locktoken to another program, Program B, also run by
User A, as Program B cannot discover the locktoken itself (due to the issues
described above). Now Program A and Program B are equally able to modify
Resource A. Resource A is it is locked by User A, and both Program A and Program
 B have the locktoken. So it would seem that section 6.5 does not describe a
mechanism for preventing these collisions, it only provides a possibility for
programs to use the communication of locktokens as sync points for concurrent
activities. It seems it is still the applications' responsibility to coordinate
their updates appropriately through some out-of-band activity like monitors,
semaphores, etc. Am I missing something?

Section 6.5 says "... a lock token MUST be submitted by an authorized principal
in the If header for all locked resources that a method may interact with or
the method MUST fail." Should this have been "... all locked resources that a
method may modify or the method MUST fail"? The example follows this rule as
the lock token destination is the only one required for the COPY method. If
this is the case, what about resource that are indirectly modified by a method?
Do their lock tokens have to be provided too? For example, consider a
collection that is not depth locked, but contains a resource that has an
exclusive lock. Deleting the collection causes the locked resource contained in
it to be modified. Does the DELETE method have to have an If header containing
the locked resource as well as the collection?

Section 6.6 says "A MOVE MUST NOT move the write lock with the resource...".
But it doesn't say what happens if this is attempted. Does the move fail on
this resource, or does the move occur and the lock is removed? I assume the
move fails on this resource but continues to move as many resources as
possible. So for example, if a user attempts to move a collection that is
unlocked, but contains a resource locked by another user, the collection is
moved, but not the locked resource. What if the resource is locked by the user
doing the move? Is the resource moved in this case? If so, is the lock
retained? It would be surprising if a user lost his locks when moving a
collection.

Section 7.10.7, What status code should be returned on an attempt to refresh a
lock on an unlocked resource? Precondition failed? Method Failure?
Unauthorized? Seems like there might need to be a Not Locked status code. Same
question for attempting to unlock a resource that is not locked. As specified,
Precondition failed will be returned as the locktoken in the request cannot
match any state of an unlocked resource. But this wouldn't be very descriptive.

Again,  thanks for the help, and sorry about the long message.

Received on Thursday, 9 July 1998 16:16:01 UTC