RE: LOCK of resource in non-existent collection & 409 response

   From: Dan Brotsky [mailto:dbrotsky@Adobe.COM]

   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?

Probably the authors felt it wasn't necessary to restate this
requirement (but I'm just guessing).

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

Yes, my interpretation is also that this is disallowed, because of
the language of 7.4.

   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.

The 409 response is fine, but the requirement that the body be empty
is not.  RFC 2616 states:

"The response body SHOULD include enough information for the user
to recognize the source of the conflict.  Ideally, the response
entity would include enough information for the user or user agent
to fix the problem; however, that might not be possible and is not
required."

   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.

OK, except for last sentence which should be deleted.

   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.

OK by me.

Cheers,
Geoff

Received on Tuesday, 20 March 2001 11:55:00 UTC