Questions on test: 39 unlock

[John Meissen]

Accroding to RFC4918:

 9.6.  DELETE Requirements

   [....]

   A server processing a successful DELETE request:

      MUST destroy locks rooted on the deleted resource

So I would agree with your interpretation. In fact I did. However, later on
it says:

 9.11.  UNLOCK Method

   [....]

   For a successful response to this method, the server MUST delete the
   lock entirely.

   [....]

   A successful response to an UNLOCK method does not mean that the
   resource is necessarily unlocked.  It means that the specific lock
   corresponding to the specified token no longer exists.

So I suppose one could argue that as long as the lock no longer exists
then a successful response should be sent. In the interests of passing the
test I changed my approach to return success if the request was for a lock
on a resource that no longer exists, since any lock which may have existed
has already been deleted.

But I think your original response is the correct one.

john-


evert at rooftopsolutions.nl said:
> Hey guys,
>
> sorry for spamming the list so much over the last hour :)
>
> I have a question regarding lock test 39.
>
> Test 38 (unmapped_lock) creates a lock on /litmus/unmapped_url (I   return 201
> Created) After that, it invokes a delete on /litmus/unmapped_url (to which I
> return 204 No Content)

> Then test 39 starts, and tries to unlock the url that was just   deleted, to
> which I return : 412 Precondition failed

> Am I supposed to retain locks of deleted urls? The RFC doesn't mention   this
> (or: I can't find it) and Lisa Dusseault's book mentions in   section 8.7.3:

> "When a resource that is directly locked is deleted, its lock   disappears",
> however.. I believe this book is based off RFC2518, and   not RFC4918.

> Evert