W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: Raw meeting notes from WebDAV WG meeting

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>
Message-ID: <JIEGINCHMLABHJBIGKBCMEEEGNAA.julian.reschke@gmx.de>

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

<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 20 March 2003 16:34:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:03 GMT