- From: Jason Crawford <ccjason@us.ibm.com>
- Date: Sat, 5 Oct 2002 13:55:14 -0400
- To: "'Webdav WG'" <nnw3c-dist-auth___at___w3c.org@smallcue.com>
- Cc:
In section 7.5 we read... 7.5 Write Locks and Collections A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URIs of the collection by non-lock owners. As a consequence, when a principal issues a PUT or POST request to create a new resource under a URI which needs to be an internal member of a write locked collection to maintain HTTP namespace consistency, or issues a DELETE to remove a resource which has a URI which is an existing internal member URI of a write locked collection, this request MUST fail if the principal does not have a write lock on the collection. However, if a write lock request is issued to a collection containing member URIs identifying resources that are currently locked in a manner which conflicts with the write lock, the request MUST fail with a 423 (Locked) status code. If a lock owner causes the URI of a resource to be added as an internal member URI of a depth-infinity locked collection then the new resource MUST be automatically added to the lock. This is the only mechanism that allows a resource to be added to a write lock. Thus, for example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c then resource /a/b/c will be added to the write lock. I think the second paragraph is only true if we're talking about a depth infinity lock. The paragraph doesn't mention that though. Another set of eyes should read this though and see if I'm just being dense... J. ------------------------------------------ Phone: 914-784-7569
Received on Saturday, 5 October 2002 14:46:39 UTC