Re: Simplifying RFC-2518 Locking: A proposal

   From: ccjason@us.ibm.com

   <ja>
   I would resist the second extension. My server currently does not associate
   anything with the lock token except the locked resource. In particular, it
   doesn't remember the URL used to lock the resource,
   </ja>

   Hey, it's just a little matter of coding. :-)

I was wondering the same thing.  It seems like a fairly easy thing to
compute.  If somebody tries to "MOVE" the resource outside of the
resources you control, you can just fail the MOVE.  Otherwise, when
someone comes at you with a URL and a Lock-Token header, just look the
pair up in your table, and perform the request on that resource.

   It sounds like the server would
   need to maintain a   lock + URI  ->  new URI mapping or something
   like that.

lock + URI -> resource.  No need for the server to indirect through
another URI mapping ... that would just make things hard.  The nice
thing about being a server is that you have real resource handles
and *don't* have to indirect through URI's.

   There really wouldn't be any point in storing it with resource.

You could just store it in the resource, and then search for it every
time you get a request, but that doesn't sound like the efficient way
to do it.

   That mapping table would need to be global (at least to the workspace).  It
   would need an entry for every URI locked by a depth lock if we plan to
   remap each of those independently.

Which is reasonable with static depth locks, and quite the pain with
dynamic depth locks, but I digress ... (:-).

   Issues...

   i1) I suspect Geoff didn't mean it, but I think he said (by using the
   word "identify") that the server "tells" the client where the resource
   has moved to.  (If this is not what Geoff meant... skip to (i2).)

You are correct, that's not what I meant (:-).  By "identify", I mean
the server figures out what the locked resource was, and applies the
method to that resource.  Clients are not involved at all, so I'll
skip to i2 ...

   i2) This proposal breaks our model whereby all webdav
   resources have parents at their analagous parent URI.  This would not
   be the case here unless URI protection were added.

I believe that there is no more breakage in this regard than
is introduced by multiple bindings.  You have a new name for a resource
*other* than the name it used to have (just like adding a binding).

Unlike a normal binding, this new name (the <lock-token,URL> pair)
is stored off in some server maintained place where clients can't
mess with it.

Now it's true that this new name effectively exists in a non-WebDAV
namespace, but WebDAV was carefully designed to ensure that these
non-WebDAV namespaces can co-exist with the WebDAV ones.
The fact that this new name is bound to the same resource that
exists in WebDAV space should cause no confusion.

   That is... a whole
   tree of URI's could be locked, but if someone does a MOVE above the
   root of that URI at which the lock request was originally directed,
   then there will be a gap in the parentage tree.

The WebDAV resource space will have no gaps.  The <lock-token,URL> name
is still valid.  It's true that you can't treat the new name as forming
a tree of any interesting kind, but that's not what it is there for.
It's a way to guarantee that a client has a reliable handle on the
resource it locked (e.g. for a subsequent PUT/UNLOCK).

   I personally don't care about this,
   but a lot of folks went through a ton of time
   defining and refining how webdav resources must have a parent at their
   parent URI.  A ton.  They must feel this is a valuable feature.  --

As do I.  If I were violating it, I'd be concerned.  I believe we
are just "supplementing" it with some additional reliable names.

   Also a lesser namespace incongruity like this was also the reason that
   it was claimed that lock null resources are a pain for the client.  If
   that was to believed there... it should be a consideration here.

That was very different.  The case against a lock null resource is that
it was a URL masquerading as a resource.  A lock null resource is just
a sleight-of-mouth (:-) for locking a name while still pretending that
there was some resource being locked.  The complexities that resulted
stemed from the fact that there really *was* no resource to hold this
lock, and so the model would break down.

   i3)
   Because this model doesn't protect a URI, it isn't just possible to
   move a locked resource from the namespace... it's also possible to
   delete it from the namespace and thus removing all apparent URI's for
   it.

except for the special <lock-token,URI> name that will continue to
provide access to it.

   Redirection won't work then.  Perhaps internal redirection would
   still though.  

The server maps this special name to a resource, not to another URI.
(Life is good, when you're a server :-).

   i4) For depth locks, we'd need to define behaivor.
   Given /a/b/c and a depth lock placed on /a/b/.  It's pretty clear what
   the redirection does for an access to /a/b/.  But what about /a/b/c?
   Does it refer to the resource that was originally at that location?

If you use the Lock-Token header, it will be the resource that was at
/a/b/c when you applied the lock.

   Or does it refer to the current "c" member of the collection that was
   orginally at /a/b/.

No, the Lock-Token is just there to guarantee access to the original resource.
If you want to play with the current members of the collection, you'd
just BIND that collection into some working collection, and then
issue your requests against that new binding without the
Lock-Token header.

   i5) We'd have to work out when the redirection is
   triggered.  It's probably not sufficient to say it's triggered when
   there is no resource at a URI.  It would need to also deal with the
   situation where a different resource is now at that location.  But
   that does create another ambiguity rlated to (i4).  Ah... it's a bit
   of a mess.  I'm not going to get into it here.

I think you're still thinking of it as a "<lock-token,URL> -> new-URL"
mapping ... it's not.  It's "<lock-token,URL> -> resource".  The server
stores this information in its lock table at the time of the lock request,
and doesn't change it until the UNLOCK request is made.  The server
knows when to use the lock table when it gets a Lock-Token header.
Otherwise it just ignores the lock table.

   and there is no special case URL mapping that would somehow add lock
   tokens to namespace resolution calculations, some of which happen
   outside my server's domain.

As long as the same server handles the same segment of the URL space
(e.g. nobody messes with the Apache config file), all requests for
Lock-Token based URL's will go to the same server.  Sure, if the
client holds onto the lock token long enough for that to no longer
apply, then it won't find the resource.  The server just handles that
like a timeout, (probably it would have timed out anyway by then :-).

   <ja> It seems like if we have to do this, we're still missing something. I
   think the solution is that if the user is conserned about someone
   moving his locked resource, then he should lock the parent
   collection. That's what locking collections is for, to control the
   namespace. </ja>

   Lacking URI protection, he'd also lock all the collections to the
   root.

No, just the subtree being worked on.  If you ever "lose" the sub-tree
you were working on, you can use your "lock-token" and the original
subtree root URL to find your sub-tree, bind it somewhere so you can
keep working on it.  If somebody moves *that* away, heck, you've still
got your lock token, and you can rebind to it as often as you need to.

As for Jim's suggestion that we do away with lock tokens, as Jason
points out, it would require designing a session mechanism, which
is probably better but more complicated than lock tokens, so it
wouldn't fit into my current "simplify 2518" jihad (:-).

Cheers,
Geoff

Received on Saturday, 16 October 1999 23:04:52 UTC