- 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