GULP 5.7, was: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)

Geoffrey M Clemm wrote:

> 
> I agree.

ok,

below the new version...:

-------------- GULP (Version 5.7) --------------

- A lock either directly or indirectly locks a resource.

- A LOCK request with a non-empty body creates a new lock, and the
   resource identified by the request-URL is directly locked by that lock.
   The "lock-root" of the new lock is the request-URL. If at the time of
   the request, the request-URL is not mapped to a resource, a new
   resource with no content MUST be created by the request.

- If a collection is directly locked by a depth:infinity lock, all
   members of that collection (other than the collection itself) are
   indirectly locked by that lock.  In particular, if an internal
   member resource is added to a collection that is locked by a
   depth:infinity lock, and if the resource is not locked by that lock,
   then the resource becomes indirectly locked by that lock.
   Conversely, if a resource is indirectly locked with a depth:infinity
   lock, and if the result of deleting an internal member URI is that
   the resource is no longer a member of the collection that is
   directly locked by that lock, then the resource is no longer locked
   by that lock.

- An UNLOCK request deletes the lock with the specified lock token.
   The request-URL of the request MUST identify a resource that
   is either directly or indirectly locked by that lock.
   After a lock is deleted, no resource is locked by that lock.

- A lock token is "submitted" in a request when it appears in an If
   header.

- If a request would modify the content for a locked resource, a dead
   property of a locked resource, a live property that is defined to be
   lockable for a locked resource, or an internal member URI of a
   locked collection, the request MUST fail unless the lock-token for
   that lock is submitted in the request.  An internal member URI
   of a collection is considered to be modified if it is added,
   removed, or identifies a different resource.

- If a request causes a directly locked resource to no longer be
   mapped to the lock-root of that lock, then the request MUST
   fail unless the lock-token for that lock is submitted in the
   request.  If the request succeeds, then that lock MUST have been
   deleted by that request.

- If a request would cause a resource to be locked by two different
   exclusive locks, the request MUST fail.



-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 14 June 2004 05:28:06 UTC