- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 27 Jun 2004 10:57:07 +0200
- To: Jason Crawford <ccjason@us.ibm.com>
- Cc: Lisa Dusseault <nnlisa___at___osafoundation.org@smallcue.com>, WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>
Jason Crawford wrote: > > 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. 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
Received on Sunday, 27 June 2004 05:12:06 UTC