RE: Raw meeting notes from WebDAV WG meeting

If current clients depend on the "can unlock
with the URL of indirectly locked resources",
then I believe we can address Julian's concern with 
an interoperability note that states "for interoperability
with older clients, a server MAY automatically redirect
an UNLOCK on an indirectly locked resource to the
lock root URL of that lock.

Note: We should also include in 2518bis the motivation for
this restriction; namely, that it prevents a client from
mistakenly unlocking an entire tree of resources when all
it wanted to do (and all it thought it was doing) was
unlocking one of the members of that tree of resources.

Cheers,
Geoff


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Thursday, March 20, 2003 4:34 PM
To: Jim Whitehead; WebDAV
Subject: RE: Raw meeting notes from WebDAV WG meeting



> 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 23:30:18 UTC