W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1999

Re: UNLOCK issues

From: <jamsden@us.ibm.com>
Date: Sun, 7 Nov 1999 10:50:27 -0500
To: Greg Stein <gstein@lyra.org>
Message-ID: <85256822.0056F82C.00@d54mta03.raleigh.ibm.com>

Greg Stein <gstein@lyra.org> on 11/06/99 10:30:01 PM

To:   w3c-dist-auth@w3.org

Subject:  UNLOCK issues

The UNLOCK method isn't documented very well with respect to its
interaction with the Depth: header or how to return errors (generally, and
in the case of a failed If: condition match).

S9.2 states that a Depth: header is only supported if the method
explicitly supports it. Am I to assume, then, that UNLOCK ignores the
Depth: header? (or should it return an error if one is present?)
All unused headers should be ignored. This wasn't specified for COPY which
doesn't use the depth header, but if its specified, it must be infinity.
Don't know why the inconsistency exists.

Presuming the UNLOCK should always be treated as Depth: 0, then an If:
failure is pretty easy. No multistatus is possible, so a 412 (Precondition
Failed) would be the response from an UNLOCK?
Actually, UNLOCK should always be treated as Depth: infinity. If you unlock
a depth locked collection, all the locked resource with that lock token are
unlocked. If you try to unlock a resource in a depth locked collection with
the collection lock token, this should fail because of inherited locks. So
a multistatus is always possible for UNLOCK because the method could fail
to unlock many resources in a depth lock.

Note there is also a bit of weirdness in that UNLOCK is Depth: 0, but that
a lock could have Depth: infinity. And that you can unlock the whole tree
of locks by unlocking any of the locked resource.
I think depth should be ignored. The thing that determines what will be
unlocked is the lock token.

Also, how do you signify failure if the UNLOCK cannot be performed? For
example, an unknown lock token or improper authorization? Let's say the
lock token isn't found. Return a 400 (Bad Request)? Now, let's say the
lock token *is* found but the authorization is wrong. Just keep returning
401 (Unauthorized) until they get it right?
That's what I did.

Well... this is somewhat rambling. To summarize:

* I think S8.11 should be explicit that the Depth: header is not used.
* There should be a summary of "typical" status codes like some of the
  other sections.
Agreed. Why don't you write something up and we'll try to cover it this


Greg Stein, http://www.lyra.org/
Received on Monday, 8 November 1999 04:48:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:19 UTC