W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 15 Dec 2005 16:14:20 +0100
Message-ID: <43A1884C.5050402@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
CC: Lisa Dusseault <lisa@osafoundation.org>, w3c-dist-auth@w3.org
Julian Reschke wrote:
>> In today's server implementations, does a LOCK of depth 0 on a 
>> collection prevent MOVE from being used to change resource names 
>> inside the collection?  This is another possible case that might be 
>> different depending on whether bindings were considered part of the 
>> collection, part of the resource state, or both.
> I'll claim that all servers that implement depth 0 locks on collections 
> work that way, and that RFC2518 requires them do work that way 
> (<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.7.5>):
> "A write lock on a collection, whether created by a "Depth: 0" or 
> "Depth: infinity" lock request, prevents the addition or removal of 
> member URIs of the collection by non-lock owners. 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."
> Again, if you have evidence of servers working differently, please 
> provide it.
> Best regards, Julian

For the record, I just tested with all servers that do support 
collection locks (SAP Netweaver, Apache/moddav, Xythos), and all of them 
require the lock token when moving things inside a locked collection 
(test case attached).

So unless there's any new evidence, it would be nice if we could stop 
arguing about this topic...

Best regards, Julian

Received on Thursday, 15 December 2005 15:24:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:34 UTC