W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

new DELETE vs collection lock issue

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 14 Jun 2004 18:32:16 +0200
Message-ID: <40CDD310.6030105@gmx.de>
To: w3c-dist-auth@w3.org

Hi,

Section 7.5 of RFC2518 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.7.5>) states...:

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

(the same text appears in RFC2518bis-05).

This is consistent with RFC2518's definition of DELETE, namely 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.6.1>):

"If the DELETE method is issued to a non-collection resource whose URIs 
are an internal member of one or more collections, then during DELETE 
processing a server MUST remove any URI for the resource identified by 
the Request-URI from collections which contain it as a member."

However the requirement to remove *all* URIs mapped to the resource is 
incompatible with BIND (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.section.2.4.p.1>) 
and has been removed in RFC2518bis-05. Thus we should rewrite section 
7.5 as:

"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 an internal member URI of a write locked 
collection, this request MUST fail if the principal does not have a 
write lock on the collection."


Jason, could you please add this to the issues list?

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 14 June 2004 12:32:55 GMT

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