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

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