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

From: Jason Crawford <[email-masked]>
Date: Sun, 27 Jun 2004 00:21:50 -0400

On Monday, 06/21/2004 at 10:37 MST, 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.

No strong preference so just go with what existing servers do. 

J.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 27 Jun 2004 10:57:07 +0200

> No strong preference so just go with what existing servers do.

What do you mean by "redirect"? Please be more specific.

No strong preference either, but some thoughts:

a) Whatever the consensus and the resolution is, it needs to be recorded 
in the official issues list. Right now it says that any URI of a 
resource protected by the lock works.

b) I think we *should* be documenting what is implemented, not what we 
think RFC2518 should have said in the first place. The servers I tested 
do implement behaviour 1).

c) If we only allow UNLOCK on the lock root, we still still need to be 
clear about what the result of other UNLOCK requests are? Undefined? 4xx 
status? In the latter case, all the servers I tested need to be updated, 
and we *may* be breaking existing clients.

Best regards, Julian

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

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 30 Jun 2004 10:23:40 -0700

Here's proposed text to use if we end up allowing UNLOCK against any 
resource covered by the lock token, as is currently the case in most 
implementations:

    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.

Lisa

On Jun 27, 2004, at 1:57 AM, Julian Reschke wrote:

> a) Whatever the consensus and the resolution is, it needs to be 
> recorded in the official issues list. Right now it says that any URI 
> of a resource protected by the lock works.
>
> think RFC2518 should have said in the first place. The servers I 
> tested do implement behaviour 1).
>
> clear about what the result of other UNLOCK requests are? Undefined? 
> 4xx status? In the latter case, all the servers I tested need to be 
> updated, and we *may* be breaking existing clients.
>
> Best regards, Julian
>
> --

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 30 Jun 2004 10:25:05 -0700

Hey, I forgot to ask.  Julian, in your research, did you happen to test 
LOCK to refresh a lock as well?  Do server implementations allow LOCK 
on any resource-URI within the scope to successfully refresh the lock?

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Jun 2004 20:08:19 +0200

Lisa Dusseault wrote:
> LOCK to refresh a lock as well?  Do server implementations allow LOCK on 
> any resource-URI within the scope to successfully refresh the lock?

Yes, I did. See 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-issues.html#065_UNLOCK_WHAT_URL> 
and in particular: 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0170.html>.

-> Servers do not care about whether the resource is directly or 
indirectly locked.

Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 30 Jun 2004 11:14:05 -0700

Yes, I read these today, but it was my interpretation that this testing  
applied to the UNLOCK request.  What about LOCK request to refresh a  
lock?  Does that also work on resources other than the lock root?  I  
think servers would probably implement them the same way, but I was  
curious whether you'd tested it explicitly.

Lisa

On Jun 30, 2004, at 11:08 AM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> Hey, I forgot to ask.  Julian, in your research, did you happen to  
>> test LOCK to refresh a lock as well?  Do server implementations allow  
>> LOCK on any resource-URI within the scope to successfully refresh the  
>> lock?
>
> Yes, I did. See  
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking- 
> issues.html#065_UNLOCK_WHAT_URL> and in particular:

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Jun 2004 20:30:19 +0200

>    resource within the scope of the lock.

Right now I'm saying:

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

..but I guess this is equivalent.

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

For the case where the lock-token header *is* present I defined:

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

so you'd get a 403 with DAV:error in this case. The more preconditions 
we precisely identify, the less new clients will have to rely on 
specific 4xx codes...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Jun 2004 20:37:54 +0200

> curious whether you'd tested it explicitly.

Sorry. Related to this is 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0191.html>, 
but that is about URLs in tagged "If" headers (where I found that 
servers do not seem to care).

Right now I'm saying...

"4.2.3.1 DAV:locks-refreshed postcondition

Timers associated with the those locks submitted in the "If" request 
header whose lock root is the resource identified by the Request-URI 
MUST be reset to their original value (or alternatively to the new value 
given in the "Timeout" request header)."

..basically because it seems nobody asked that question before. 
Assuming we'd find out that servers do not care for LOCK/refresh either, 
would we want to relax the spec text?

Best regards, Julian