W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

Re: Issue: UNLOCK_WHAT_URL

From: Dan Brotsky <dbrotsky@adobe.com>
Date: Mon, 8 Jul 2002 14:16:37 -0700
To: w3c-dist-auth@w3c.org
Message-Id: <FCF23066-92B7-11D6-B821-0003931036B4@adobe.com>

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 GMT

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