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

Received on Friday, 15 October 1999 13:48:50 UTC