W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2001

LOCK of resource in non-existent collection & 409 response

From: Dan Brotsky <dbrotsky@Adobe.COM>
Date: Mon, 19 Mar 2001 22:21:58 -0800
Message-Id: <4.2.2.20010319221955.01468cb0@mailsj.corp.adobe.com>
To: w3c-dist-auth@w3c.org
(I sent this last July, but there was no discussion and it doesn't appear on the issues list.  So I'm resending in an attempt to get it on the issues list. -dan)

In the discussion of PUT, MKCOL, COPY, and MOVE it is made very clear that attempting to create a resource not all of whose parent collections exist MUST result in a 409 response.  But in the discussion of LOCK there is no such requirement.  Why?

At first I thought that perhaps the intent was to allow reserving a particular name, and only if that name was available (i.e., the lock succeeded) would the client create the intermediate collections.  But this scenario, aside from its doubtful utility, seems to contradict the language of section 7.4 which says that a (write-)lock-null resource MUST appear as a member of its parent collection (which doesn't exist in this case).

I realize that the 409 response is already mandated when an attempt to lock an existing collection (other than at depth 0) conflicts with existing locks on members (at some level).  But there is no possible confusion between this use of 409 and the one I am proposing.

So I propose the following clarifications:

1. In section 8.10.1, add the following paragraph:

A LOCK request on a non-existent resource without an appropriately scoped parent collection MUST fail with a 409 (Conflict) response whose body is empty.

2. In section 8.10.7 add the following:

409 (Conflict)  Case 1. A non-existent resource cannot be locked at the destination until one or more intermediate collections have been created.  There MUST be no response body.
Case 2. A LOCK request (depth > 0) on an existing collection would conflict with existing locks on members of the collection.  The response body SHOULD be a multi-status indicating the members in conflict.

      dan

Dan Brotsky, Adobe Systems
Received on Tuesday, 20 March 2001 01:23:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:55 GMT