Re: DELETE leaving a lock-null resource; was LOCK Scenarios

   From: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>

   <yg/> The suggestion has been made that we introduce transactioning. I
   hope you will not think me cheeky if I summarily reject the suggestion
   of using transactioning. ...

<gmc/> I agree with Yaron that we do not want to bite off general
transactioning support as part of WebDAV.

   <yg/> BTW, in so far as what happens when you DELETE a locked resource I
   completely oppose the suggestion that DELETING a resource results in a
   lock-null resource. That is absolutely contrary to the definition of DELETE.
   DELETE deletes the resource not the name. Since the lock is associated with
   the resources deleting a locked resource deletes both the resource and the
   lock.

<gmc/> If lock were *really* just associated with the resource, I'd be a
happy camper.  For one thing, it would mean that when multiple URL's
are mapped to a single resource, you could issue the LOCK against any
of those URL's and the result would be identical.  Similarly, you could
later on issue on UNLOCK against any of those URL's and again, the result
would be identical.

<gmc/> But I have seen various arguments in the past that a LOCK should
also protect the URL to resource mapping.  If "protect" just means
"keep from being deleted", then your conclusion still holds, i.e.
it makes no sense to LOCK a deleted resource.  But if protect also
means "reserves the right to change the URL to resource mapping",
then it is perfectly sensible to keep a LOCK after the resource is
deleted (that is pretty much what a lock-null resource is anyway).

<gmc/> I personally believe that the best answer is to fix the LOCK
semantics so it *really* is just on the resource (and not on the
name).  Then things are simpler and consistent, even in the case of
multiple URL mappings to a resource.  Rather than "protecting" a URL
to resource mapping, I'd propose that a locked resource be allowed to
MOVE (this is just a change to the state of the parent collection, not
to the state of the resource being moved), but that an attempt to
access the MOVE'd resource with that lock just returns a 302 indicating
where it has MOVE'd to.

<gmc/> And as for the question of whether DELETE deletes all bindings
to a resource or whether it just DELETE's the binding named in the
DELETE request-URL, I am an adamant supporter of the current advanced
collection protocol specification which states that it *only*
deletes the binding named in the DELETE request-URL.  This behavior
is *essential* in order to allow versioning-unaware clients to
be able to issue a DELETE without destroying the history of a
resource.

<gmc/> So there are really multiple threads here:
- Should locking be on a resource or also/instead on a URL-to-resource
  mapping?  (we know what it is now, but what *should* it be)
* I vote "on a resource".
- Does a DELETE delete all bindings to a resource, or just the one
specified in the request-URL.
* I vote "just the one named by the request-URL".
- Should a DELETE delete a LOCK?
* I vote, "no".  A DELETE modifies the state of the collection containing
  the binding, not that of the resource.  In particular, all other
  mappings to that resource will continue to exist and display the
  LOCK'ed semantics.  If you want to prevent a DELETE, you put the
  LOCK on the collection whose state is being modified.

<gmc/> I realize that this requires changes to 2518, and I would not
make such a suggestion lightly.  The problem is that 2518 was specified
without the use cases of multiple bindings and versioning in mind,
and needs to be revisited now that those use cases have been elaborated.

Cheers,
Geoff

Received on Friday, 24 September 1999 05:48:24 UTC