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

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

Received on Saturday, 10 July 2004 20:48:54 UTC