Subject: Re: Call for consensus on UNLOCK Request-URI being lock root

From: Joe Hildebrand <[email-masked]>
Date: Sat, 10 Jul 2004 18:48:06 -0600

July 6 has passed.  It looks to me like we have consensus on option 1,  
with the following reasons:

- This is what existing implementations do
- It's one possible way of reading 2518
- It doesn't conflict with other decisions that have already been made

I didn't see any objections to Lisa's proposed wording:

     The UNLOCK method identifies a lock to remove with the lock token in
     the Lock-Token request header.  The Request-URI MUST identify a
     resource within the scope of the lock.

Then later in the error code information for UNLOCK:

     400 (Bad Request) - No lock token was provided, or request was
     made to a Request-URI that was not within the scope of the lock.

Also, it appears that we have consensus that refreshing locks should  
work the same way, namely, that you can refresh a lock by sending a  
LOCK request to any URI covered by the lock.

--  
Joe Hildebrand
Denver, CO, USA

On Jun 21, 2004, at 11:37 AM, Lisa Dusseault wrote:

>
> This would overturn a consensus that had previously been determined at  
> a WG meeting that happened together with an interoperability meeting,  
> and the consensus was not challenged on the mailing list at that time.
>
> However, given that we have new information -- actual research!   
> (thanks) -- it does make sense to reconsider.
>
> WG members please indicate your old, new, and/ or current preference,  
> with reasons if they've not already been stated here:
> 1. Should servers accept an UNLOCK request where the Request-URI names  
> any resource covered by the lock named in the lock token?
> 2. Or, should servers redirect that UNLOCK request to the root of the  
> lock?
> 3. If something else, please explain.
>
> Part of the rationale for #2 in the original consensus was to make  
> sure that clients understood the scope of the lock they were  
> attempting to remove -- so that the entire collection, if previously  
> marked as locked, would now be shown as unlocked, rather than just the  
> resources covered by the Request-URI.
>
> Please indicate your preference by July 6.
>
> Lisa
>
> On Jun 21, 2004, at 10:31 AM, Julian Reschke wrote:
>
>>
>> Lisa Dusseault wrote:
>>
>>> I'm fine with 1 and 2, but I don't understand problem #3.
>>> What this text attempts to say is that the server SHOULD redirect an  
>>> UNLOCK request to the correct URI if the UNLOCK request has the  
>>> wrong URI for the lock token -- that's the ideal response.  If the  
>>> server can't do that, then as Plan B, the server MAY [or SHOULD?]  
>>> return a simple error.
>>> What's wrong with a specification having a Plan B if the software  
>>> can't do Plan A for some reason?  Returning errors is the typical  
>>> Plan B anyway...
>>> I agree the text needs a little more specifics about what kind of  
>>> redirect -- suggestions?
>>
>> Well, if in the context of an HTTP related spec you talk about  
>> "redirecting" something, many will read that as having to do with a  
>> 3xx status code. I'm still not sure whether this is what you intend  
>> to say or not.
>>
>> If, on the other hand, you're saying that the server SHOULD accept  
>> the UNLOCK even if the request URI is only indirectly locked (and  
>> just do the unlock then), then it doesn't make sense to add any more  
>> text. As Geoff pointed out recently about text *I* did write, saying  
>> "server SHOULD do 'x' and MAY do not('x')" is bad specification text;  
>> it only confuses the audience.
>>
>> Anyway, quoting myself in
>>
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/ 
>> 0170.html>:
>>
>> "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>."
>>
>>
>> ...and that's what I did with (a) my draft and (b) GULP (they both  
>> are now consistent with what the issues list states as working group  
>> consensus, see issue 65).
>>
>> Best regards, Julian
>> -- 
>> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>>
>

---

From: Julian Reschke <[email-masked]>
Date: Sun, 11 Jul 2004 12:56:57 +0200

>     resource within the scope of the lock.

I'd prefer something that actually focuses on what the method does (the 
purpose of UNLOCK is not to identify a lock; it's to remove it), such as:

"The UNLOCK method removes the lock identified by the lock token in the 
Lock-Token request header from the resource identified by the 
Request-URI, and all other resources included in the lock. Note that the 
UNLOCK request may be submitted to any resource locked by that lock 
(even those that are locked indirectly)." 
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.section.5.p.1>)

>     made to a Request-URI that was not within the scope of the lock.

Here, I'd prefer that we define specific precondition codes that more 
clearly describe the problem:

"5.2 Preconditions

5.2.1 DAV:lock-token-matches precondition

The lock identified by the "Lock-Token" request header exists, and the 
resource identified by the Request-URI indeed is directly locked by the 
specified lock.

5.2.2 DAV:lock-removal-allowed precondition

As dicussed above, the principal authenticated for the UNLOCK request 
MUST be allowed to remove the identified lock (note that servers that 
support the "WebDAV Access Control Protocol" should use the 
DAV:need-privileges precondition defined in section 7.1.1 of 
[RFC3744])." 
(<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html#rfc.section.5.2>)

> LOCK request to any URI covered by the lock.

Yes.

Best regards, Julian