Re: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)

Julian Reschke wrote:

>> I just noticed that in
>>
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>
>>
>> we write...:
>>
>>   "An UNLOCK request deletes the lock with the specified lock token.
>>   The request-URL of the request MUST identify the resource that
>>   is directly locked by that lock.  After a lock is deleted,
>>   no resource is locked by that lock."
>>
>> This was a change to the previous GULP version. However, the 
>> discussion attached to issue entry UNLOCK_WHAT_URL 
>> (<http://www.webdav.org/wg/rfcdev/issues.htm>) seems to indicate that 
>> we agreed upon allowing any URL protected by the lock to be used as 
>> request URL.
>>
>> 1) We should agree on one of the two; and fix the other document 
>> accordingly.
>>
>> 2) RFC2518 seems to allow both interpretations:
>>
>>    "The UNLOCK method removes the lock identified by the lock token
>>    in the Lock-Token request header from the Request-URI, and all
>>    other resources included in the lock."
>>
>> 3) Back when I tested this, both Apache/moddav and Xythos were 
>> implementing this, and so are we (I think). Microsoft IIS doesn't 
>> support deep locks, so it's not relevant here.
>>
>> Therefore it seems that we should undo that particular change from 
>> GULP 5.5 for the sake of interoperability with older clients that may 
>> rely on it (this seems to be harmless).
> 
> 
> Adding to the confusion, I just find out that RFC2518bis-05 says it 
> needs to be directly locked as well (well, I guess it *tries* to say 
> that, see... 
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0115.html>).
> 
> Can we please make a decision *and* make sure that it's tracked on the 
> issues list? An issues list that is not only out of sync but even 
> contradicts the latest draft really doesn't help much :-)

OK,

here are some actual test results:

a) Apache/moddav: allows UNLOCK on indirectly locked resources,
b) Xythos: same,
c) SAP Enterprise Portal: same,
d) Microsoft IIS: no support for depth infinity locks.

Thus the current text in the issues resolution "Resolved that you can 
specify any URL locked by the lock you want to unlock" does indeed 
reflect current implementation experience, and this is what spec 
revisions should be saying.

Thus:

1) RFC2518bis should undo that change, and
2) GULP should be updated accordingly (I'll do that for my in-document 
copy of GULP at 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.section.C>.


Best regards, Julian


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760