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

Lisa Dusseault wrote:

> I thought a little more about exactly how the redirect would work and 
> there's a number of options, none of them very good.  I think this is 
> moot since we seem to prefer #1 accepting the UNLOCK request even on the 
> "wrong" URL, but a little discussion anyhow...
> ...

OK, I think we clearly have reached consensus to allow clients to 
specify an indirectly locked resource in UNLOCK requests. This is because

- this is what servers do implement,
- what the issues list already mentioned as resolution for issue 65 
(UNLOCK_WHAT_URL) (<http://www.webdav.org/wg/rfcdev/issues.htm>)
- this is what GULP states after the changes discussed here some weeks 
ago 
(<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0177.html>)

So please

- update the issues list accordingly (issue 
LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY can be closed as well)
- revert the change in RFC2518bis-05, possibly only clarifying the 
original language

In 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-latest.html>, 
I already say:

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

I'll also mark the issue 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking-issues.html#063_LOCKS_SHOULD_THEY_USE_AN_IF_HEADER_TO_VERIFY> 
closed.

Best regards, Julian

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

Received on Saturday, 10 July 2004 05:16:34 UTC