Subject: Re: Simplifying RFC-2518 Locking: A proposal

From: [email-masked]
Date: Fri, 15 Oct 1999 15:32:21 -0400

---------------------- Forwarded by Jim Amsden/Raleigh/IBM on 10/15/99 03:32 PM
---------------------------

Jim Amsden
10/15/99 03:28 PM

To:   "Geoffrey M. Clemm" <[email-masked]>
cc:

Subject:  Re: Simplifying RFC-2518 Locking: A proposal  (Document link: Jim
      Amsden)

I'm all for it.

You also loose the ability to reserve a name in the namespace by locking a
resource that doesn't exist. (Boy when you say it that way, it really doesn't
make sense).

I would resist the second extension. My server currently does not associate
anything with the lock token except the locked resource. In particular, it
doesn't remember the URL used to lock the resource, and there is no special case
URL mapping that would somehow add lock tokens to namespace resolution
calculations, some of which happen outside my server's domain. It seems like if
we have to do this, we're still missing something. I think the solution is that
if the user is conserned about someone moving his locked resource, then he
should lock the parent collection. That's what locking collections is for, to
control the namespace. Alternatively, we can fail any move whose souce is
locked, and the requesting principal either doesn't own the lock, or didn't
specify the lock token. The confusion here is that PUT and DELETE are resource
methods that effect their parent collection as a side effect. It would be better
to have some addMember/removeMember methods on a collection to do this. The
problems result form the behavior being in the wrong place. But this is
inherited from HTTP which didn't have collections, so we'll have to work around
it.

Now, while we're on a role, how about getting rid of those pesky lock tokens!
The only thing they seem to do is let a particular principle who is running
concurrent authoring applications that might be updating the same resources
detect the possibility of overwrite conflicts by distinguishing which
application got the lock token by doing the LOCK, and which one got it from some
other mechanism (like IPC or the user typed it in). The application that
directly got the lock could proceed with its operation while the others could
put up a warning indicating there might be some other application that could be
updating the resource at the same time, and you might want to think about
whether you want to do this operation now or not. (Now there's a warning for
you). It took me quite a while to figure this out, and I may not have it right
yet, but that's my interpretation of the spec. Note that clients don't have to
do anything with the lock token except hang on to them and send them back when
needed. The above is just a suggested convention. Not also that having a lock
token doesn't give any other principle any privilege as you must own a lock
token to be able to use it. I submit the problem being solved is not worth the
protocol complexity and client inconvence (having to retain all those lock
tokens). Note also that other systems either associate the lock with the process
id (which we can't do in an HTTP server), or let the user be responsible for
concurrent process he might have started up. I'd be happy that.

"Geoffrey M. Clemm" <[email-masked]> on 10/15/99 01:48:45 PM

To:   [email-masked]
cc:

Subject:  Simplifying RFC-2518 Locking: A proposal

Encouraged by some degree of enthusiasm expressed on this list for
simplifying RFC-2518 locking, I've modified my earlier non-proposal in
light of the recent discussions on the mailing list, and now have a
real "proposal" to make.

**********

A LOCK/UNLOCK request without a depth header places/removes a lock on
exactly one resource (the resource identified by the request-URL).  A
LOCK/UNLOCK request on a URL that is not mapped to a resource will
fail with a 404.  You can use a depth header to place/remove locks on
a collection and its members at the time of the lock.  This
placement/removal of locks MUST be performed atomically, or the LOCK request
MUST fail.

Only an explicit LOCK request ever adds a lock to a resource, and only
an explicit UNLOCK request ever removes a lock from a resource.  In
particular, locks are not deleted as a side effect of a MOVE or a
DELETE, and locks are not added as a side effect of a MOVE due to
"inheriting a lock" from a collection.

A request fails with a 423 if the request would modify the state of a
write-locked resource for which you don't hold the lock token.  The
state of a basic resource is its body and its dead properties.  The
state of a collection is its set of bindings and its dead properties.
A write-lock request on a resource that is already write-locked will
fail with a 423.

**********

And that's it.  This does lose some functionality.  It doesn't guarantee
that your handle on a locked resource will always be valid, and it doesn't
allow you to "add a resource" to a lock.  If one or both of these
are considered essential, I would be willing (but not happy :-) to add
one or both of the following extensions:

A Lock-Token header containing a lock token returned by a prior LOCK
request can be included in a subsequent LOCK request to extend an
existing LOCK.  A server may fail this request if the specified
lock token cannot be extended to the specified resource.

A Lock-Token header may be included in any request, which
will cause the request-URL to identify the resource that was identified
by that URL at the time it was locked with that lock token.

**********

I'll know Yaron is back from traveling when my in-box suddenly
bursts into flames before my eyes (:-).

Cheers,
Geoff

---

From: Jim Whitehead <[email-masked]>
Date: Sun, 17 Oct 1999 17:13:02 -0700

> Now, while we're on a role, how about getting rid of those pesky

... and while we're at it, let's break the majority of existing WebDAV
clients.

For example, if lock-tokens were removed from the spec., existing clients
that request a lock will be surprised when they do not receive a lock token
back in the response, and will flag an error.

> The only thing they seem to do is let a particular principle who
> is running concurrent authoring applications that might be updating the
same
> resources detect the possibility of overwrite conflicts by distinguishing
which
> application got the lock token by doing the LOCK, and which one
> got it from some other mechanism (like IPC or the user typed it in). The
application that
> directly got the lock could proceed with its operation while the
> others could put up a warning indicating there might be some other
application
> that could be updating the resource at the same time, and you might want
to think about
> whether you want to do this operation now or not. (Now there's a
> warning for you). It took me quite a while to figure this out, and I may
not
> have it right yet, but that's my interpretation of the spec.

This is the rationale for this feature.

> I submit the problem being solved is not worth the
> tokens).

You may be right. But, at this point, more interoperability problems would
be introduced by "fixing" this problem than would be removed by removing
lock tokens.  As your implementation experience shows, client-side handling
of lock tokens is simply tedious, and isn't a show-stopper.  Given a
tradeoff between potentially show-stopping interoperability problems with
existing clients (removing lock tokens from 2518), and a non-show-stopping
programming tedium (keeping things as is), I'm very much in favor of the
status quo.

- Jim

---

From: [email-masked] (WJCarpenter)
Date: Mon, 18 Oct 1999 14:58:09 -0700

jw> ... and while we're at it, let's break the majority of existing
jw> WebDAV clients.

IMHO, WebDAV is not so mature at this point that it is out-of-bounds
to break existing implementations.  Of course, what is sufficiently
important for that is a bit subjective.  One can see these distinct
groups of implementations today, both in clients and servers:

1.  Nobody much using them.  (We don't care if they're broken by a
    change)

2.  Nobody keeping them up.  (Many of these are broken in other
    interesting ways ... if their creators don't care, why should we?)

3.  Actively maintained.  (Authors of these will accommodate reasonable 
    changes.  In fact, as others have mentioned from time to time,
    they would be happy to rip out implementations of hairy things
    even though they have already gone to all the bother of putting it 
    in in the first place.)

jw> For example, if lock-tokens were removed from the spec., existing clients
jw> that request a lock will be surprised when they do not receive a lock token
jw> back in the response, and will flag an error.

Before I got around to implementing real LOCKs and tokens, I just
returned the same static string for every request.  This doesn't cover 
all cases and all scenarios, but for a client to object it would
probably have to be correlating multiple LOCK tokens against different 
resources, and it would have to care about that.
-- 
[email-masked]   (WJCarpenter)           PGP
[email-masked]                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3