RE: Locking questions

Sure, I'll take a T-shirt - large. But, I don't think we're out of the woods
yet. There are still a couple of problems. First, as you already noted, there
is no way for an application that has "lost" a lock token to use a
lockdiscovery property to get it back. Using the owner element hack is a
work-around, but would result in non-standard servers. Another is for the
application to just try each lock token until it finds one that works. Pretty
ugly. This really limits the usefulness of lockdiscovery too.

Worse than this though is that locking on the server can't work for the same
reason. Say a principal submits a PUT request on a locked resource. The If
header contains a precondition containing the appropriate lock token for the
locked resource. However, the server can't determine if the requesting
principal owns the given lock token! This is because the server can't lookup
the lock using a lockdiscovery since it's activelock elements don't contain the
principal. So there is no way for the server to determine if the resource is
locked by the requesting user. If you leave out the principal and don't match
on it in the server, then any application could get any lock token it wanted
out of the lockdiscovery property and modify anything. Servers could of course
use some other mechanism to attach principals to lock tokens, but this
re-introduces the same authorization id problem that DAV was trying to avoid.
It would also fragment lock information producing poor encapsulation in
implementations. In addition, DAV wouldn't have proper "closure" in that it
wouldn't save information it requires to meet its own semantics.

It all boils down to you can't have principal based locking without the
principal. I suggest DAV use the userid from the Basic or Digest scheme and
that all methods requiring access permission (e.g., any method that updates a
locked resource in this version of DAV) submit an Authorization header. When
ACLs are introduced, there will have to be some upward-compatible way to
identify a principal. The reason for using the userid instead of the whole
authorization header is to avoid the particularities of the authorization
schemes. It is highly likely that any ACL, authorization, or locking scheme
will have to identify principals as that's kind of the point.

Another suggestion: LOCK should return an activelock elmement, not a
lockdiscovery. 99.99% of the time, its the lock token just granted the
application needs, and if more information is needed, use PROPFIND to get the
lockdiscovery. This simplifies client applications significantly.






w3c-dist-auth-request@w3.org on 07/15/98 03:17:46 PM
Please respond to w3c-dist-auth-request@w3.org
To: ejw@ics.uci.edu, w3c-dist-auth@w3.org, Jim Amsden/Raleigh/IBM@ibmus
cc:
Subject: RE: Locking questions

Jim, you were absolutely right, we got a bug in the spec.

Insert after section 6.1:

"6.2 Write Locks and Lock Tokens

A successful request for an exclusive or shared write lock MUST result in
the generation of a unique lock token associated with the requesting
principal. Thus if five principals have a shared write lock on the same
resource then there will be five outstanding unique lock tokens."

Add to the end of the last paragraph in section 7.10.1:

"If the LOCK request was for a new lock and was successful then the
Lock-Token response header MUST be included in the response in order to
indicate the lock token associated with the newly created lock. That is, the
Lock-Token header would not be returned with a successful refresh LOCK
request because a new lock wasn't created."

Replace Section 8.5 with:

"8.5 Lock-Token Header

Lock-Token = "Lock-Token" ":" Coded-URL

The Lock-Token request header is used with the UNLOCK method to identify the
lock to be removed.  The lock token in the Lock-Token request header MUST
identify a lock that contains the resource identified by the Request-URI as
a member.

The Lock-Token response header is used with the LOCK method to indicate the
lock token created as a result of a successful LOCK request to create a new
lock."

For the record I believe this error made it into the spec because at the
last minute I proposed and the group accepted removing the lock-token
response header as it was "redundant" because we returned the lockdiscovery
information in all LOCK responses. As you discovered Jim, the header was not
redundant at all because we do not yet have a mechanism for generically
identifying principals.

What I'm now wondering is if Jim is the only one who has tried to implement
shared locks. I figure he must be or this one would have shown up earlier.

Normally finding an error of this magnitude would earn you an entry in the
Acknowledgement section, but you are already there. I don't suppose we can
just buy you off with a Microsoft DAV T-shirt? =)

  Yaron



> -----Original Message-----
> From: Yaron Goland
> Sent: Tuesday, July 14, 1998 5:20 PM
> To: 'Jim Amsden'; w3c-dist-auth@w3.org
> Subject: RE: Locking questions
>
>
> > <jra>
> > But there may be many shared locks in the lockdiscovery
> > property. How would an
> > application figure out which one was the one just created for
> > this user? I see
> > that it works with exclusive locks because there can only be one.
> > </jra>
>
> So we agree that we can always resolve the proper lock token
> for an exclusive lock, the question now is how to handle a
> shared lock. I believe that the core of your misunderstanding
> is that you believe that when a shared lock is issued there
> will be multiple lock tokens for each owner of the shared
> lock. That is not the case. A shared lock has one and only
> one lock token assigned to it, regardless of the number of
> owners. Thus if you ask for a shared lock and you get back a
> successful result then you need only examine the body to find
> out which entry describes the shared lock you asked for (by
> definition there can be only one) and you know which one
> identifies your lock token.
>
> A further legitimate issue is how to identify your lock in
> the case where you have "lost" your memory. Again the owner
> header can be useful here. Shared locks are free to add
> multiple entries inside of owner so a client can always
> recognize its own owner entry.
>
> However I certainly believe that the world will be a better
> place when the standard principal identifier is agreed on by
> the ACL types.
>
> > <jra>
> > But DAV did specify Basic (with SSL) and Digest authorization
> > schemes must be
> > supported for security. They both provide the principal
> > userid. Couldn't this
> > be used?
> >
> > Next, the temporary hack couldn't be relied upon as not all
> > servers would
> > necessarily do it the same way.
> >
> > So I still don't see how an application can get the lock
> > token from the lock it
> > just requested.
> > </jra>
> >
>
> However SSL uses a completely different principal identifier
> (a certificate). Rather than try to shoe horn a "universal"
> principal identifier we decided to punt the problem to the ACL group.
>
>
>    Yaron
>

Received on Wednesday, 15 July 1998 20:37:35 UTC