- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 20 Mar 2003 22:34:26 +0100
- To: "Jim Whitehead" <ejw@cse.ucsc.edu>, "WebDAV" <w3c-dist-auth@w3.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Thursday, March 20, 2003 10:09 PM > To: WebDAV > Subject: RE: Raw meeting notes from WebDAV WG meeting > > > > > Jason Crawford writes: > > << > > * Discussion of "First problem" slide. What should be the behavior on > > a LOCK on an indirectly locked resource? Should the lock remove the > > entire depth lock, or should it be redirected, or should it fail? > > Rough consensus for failure, error code to be determined later. > > >> > > Jim, could you publicly clarify this one. I'm not sure what > it's refering > > to. > > Sure. For example, say you have the following set of resources: > > C1 > / | \ > a C2 b > / \ > d e > > C1, C2 are collections > a, b, d, e are non-collection resources > C1 contains a, C2, b > C2 contains d, e > > If a Depth infinity lock is taken out on C1, using the > terminology from the > meeting (really from Geoff Clemm's GULP proposal), resource C1 is directly > locked, and resources a, C2, b, d, e are indirectly locked (that is, they > were not the target of the LOCK request). > > Given this terminological background, the question is, what is > the behavior > of "UNLOCK" (the raw meeting notes are in error -- they say LOCK, > and should > say UNLOCK) if applied to any of a, C2, b, d, or e? The three choices > discussed were: > > 1) remove the entire depth lock (i.e., is equivalent to an UNLOCK on C1) > 2) be redirected to C1 using HTTP redirection (3xx) > 3) fail (4xx) > > The rough consensus in the meeting was that the response should > fail (choice > #3). In theory, this makes a lot of sense (UNLOCK should be applied to the URL to which the original LOCK request was sent). In practice, old clients that want to break a lock (after finding it using lock discovery) may get into trouble by that change (if it is a change), because in RFC2518, there was no cheap way to find the root of a lock. Note that issue "UNLOCK_WHAT_URL" (on the issues list) says that you can use any of the URLs protected by the lock. Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 20 March 2003 16:34:38 UTC