- From: Dan Brotsky <dbrotsky@adobe.com>
- Date: Mon, 8 Jul 2002 14:16:37 -0700
- To: w3c-dist-auth@w3c.org
I agree they should be rejected, but I thought there was some question
of what the error should be.
dan
On Monday, July 8, 2002, at 12:10 PM, Jason Crawford wrote:
> I've changed the issue name to the one on the issue list that seems
> more appropriate. See new Subject: line.
>
> > So do we have agreement that *any* of the URIs affected by a deep
> lock can
> > be used to do the UNLOCK operation?
>
>
> The other question of that issue is... do we agree that if you request
> an UNLOCK
> on a resource that is not locked by that lock, that the request should
> fail?
>
> I believe in previous discussions it was suggested that we should not
> allow one
> to specify a URL other than one that is locked by the lock. The
> reasoning was
> that in a virtual website where the URI space might be partitioned and
> delegated
> across several machines (perhaps using intermachine BIND requests), it
> might be
> burdensome for all machines of the virtual website to be familiar with
> all locks.
>
> Anyway, regardless of folks believing this, I'd like to confirm that
> UNLOCK requests
> specifying a request URI of an unlocked resource should be rejected.
>
> Opinions?
>
> J.
>
>
> ------------------------------------------
> Phone: 914-784-7569, ccjason@us.ibm.com
>
"Julian Reschke" <julian.reschke@gmx.de>
>
>
>
>
>
> > To: Daniel Brotsky <dbrotsky@adobe.com>
> > Cc: "Clemm, Geoff" <gclemm@Rational.Com>, w3c-dist-auth@w3c.org
> > Message-ID: <OF7C4220CB.830F87EE-ON85256B41.006F0EFA@pok.ibm.com>
> > From: "Jason Crawford" <ccjason@us.ibm.com>
> > Date: Mon, 14 Jan 2002 15:19:50 -0500
> > Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER
> >
> >
> > > In addition to Geoff's answer:
> > > If you are an administrator trying to unlock a resource obtained by
> > > someone else, you have to be able to figure out which resource to
> > > unlock. You can't unlock an internal member of a collection that's
> > > locked by a depth-inifinity lock without knowing which collection
> was
> > > actually locked.
> >
> > CAN'T?
>
> (going back to an old discussion...)
>
> RFC2518, 8.11 says [1]:
>
> "The UNLOCK method removes the lock identified by the lock token in the
> Lock-Token request header from the Request-URI, and all other resources
> included in the lock. If all resources which have been locked under the
> submitted lock token can not be unlocked then the UNLOCK request MUST
> fail.
> "
>
> So do we have agreement that *any* of the URIs affected by a deep lock
> can
> be used to do the UNLOCK operation?
>
>
> [1] <http://greenbytes.de/tech/webdav/rfc2518.html#METHOD_UNLOCK>
>
>
>
Received on Monday, 8 July 2002 17:17:14 UTC