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

From: "Dan Brotsky" <[email-masked]>
Date: Mon, 19 Mar 2001 22:21:58 -0800

(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

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 21 Mar 2001 18:08:25 -0800

I've added the issues raised by Dan Brotsky and Hatmut Warncke to the issues
list:

http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html

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

Sorry about this -- this must have been a victim of my PhD dissertation
writing efforts.

- Jim

---

From: "Julian F. Reschke" <[email-masked]>
Date: Tue, 27 Mar 2001 17:44:05 +0200

Hi,

the redirect references draft says that a redirect reference resource may
have a body:

<http://www.greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol
-02.html#rfc.section.4.p.5>.

However, MKRESOURCE will create empty resources:

<http://www.greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol
-02.html#rfc.section.5.1.p.9>,

and PUT with Apply-To-Redirect-Ref header set will replace the redirect ref
resource by a regular resource:

<http://www.greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol
-02.html#rfc.section.6.2>.

So, how can I create a redirect ref *with* a body?

Julian