W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1999

Simplifying RFC-2518 Locking: A proposal

From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
Date: Fri, 15 Oct 1999 13:48:45 -0400
Message-Id: <9910151748.AA20014@tantalum>
To: w3c-dist-auth@w3.org

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 (:-).

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:20 UTC