Re: UNLOCK issues

   From: jamsden@us.ibm.com

   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?)

   <jra>
   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.
   </jra>

I agree that unused headers should be ignored.  The header will often
be something that would make sense to a more advanced server.  This does
mean you lose the error check for clients that are issuing the wrong header
but it's probably worth paying that price in order to simplify the life of
client writers.

   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?
   <jra>
   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.
   </jra>

I'd just say that the depth header is irrelevant to the UNLOCK command,
rather than saying it should be treated as Depth:infinity.  If you happen
to be deleting a depth-infinity lock rooted at the request-URL, then the
Depth:infinity header is redundant.  If the request-URL is not the root
of the lock, or if the lock is not depth-infinity, then the Depth:infinity
header would either be ignored or generate an error.  A header that must be
either redundant, ignored, or wrong is not a useful header (:-).

   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.
   <jra>
   I think depth should be ignored. The thing that determines what will be
   unlocked is the lock token.
   </jra>

I agree.

Cheers,
Geoff

Received on Thursday, 11 November 1999 14:24:48 UTC