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

   From: Jim Whitehead <ejw@ics.uci.edu>

   Edgar Schwarz write:
   <es/> So a server could just remember lock tokens together with
   old and new URLs and keep this data until it is accessed by the locker
   or the lock expires.

   <ejw> I'm not convinced this will work, since it only handles the case
   where the resource is moved just once.  What happens if a resource is
   locked, then moved, and moved again?  How many steps is the server
   required to remember?

Subsequent MOVE's are not relevant.  The server is responsible for
retrieving the same resource whenever the client gives it a URL
and a lock token (think of it as a private binding that the server
keeps around).  The server could do this by just refusing to MOVE
or DELETE the resource (as is required by the current 2518 draft),
or by just remembering what resource is associated with that
<URL, lock-token> pair.  All we are doing here is giving the server
some additional flexibility in implementation that was constrained
by the current language in 2518.

Note: if a lock-token is included in a MOVE or DELETE request, it is
used to satisfy any locks on the source and destination *collections*.
Locks on the resource being moved or deleted are not even inspected
(since the state of the resource being moved or deleted is not being
modified).

Cheers,
Geoff

Received on Friday, 24 September 1999 18:05:02 UTC