Re: [Bug 23] lock discovery vs shared locks

Lisa Dusseault wrote:
> 
> I'm still concerned about a possible inconsistency here.  Sorry if I'm 
> being dense, but I thought that we had a previous consensus (a long time 
> ago) that servers SHOULD provide lock tokens for all locks so that if 
> there were a client bug, a crash, a LOCK reply "lost in the mail", or a 
> need for an owner or administrator to remove somebody else's stale 
> lock.  Some text currently in the draft to that extent:
> 
>   "Anyone can
>    find out anyone else's lock token by performing lock discovery."
> 
> So given that implies that lock discovery can find out all lock tokens 
> (given permission), and that the lockdiscovery property is returned in 

That's not guaranteed. Servers are currently not to required to reveal 
locks, and if they do, they aren't required to reveal the individual 
lock tokens. Note that <locktoken> is optional in <lockdiscovery> 
(<http://greenbytes.de/tech/webdav/rfc2518.html#ELEMENT_activelock>).

> the LOCK response body, doesn't that mean that the lock token is 
> returned both in the LOCK response headers (Lock-Token) and body?

It may, but clients can not rely on it.

> Also, we had previously discussed at an interop which is the "right" 
> place to put the lock token and concluded that servers ought to put the 
> token in both places because we found during interoperability testing 
> that we had clients that looked in one place, and other clients that 
> looked in the other, so we might as well continue supporting both.

Again: the only *reliable* way to obtain the new lock token is to parse 
the Lock-Token response header. Anything else may not work because (a) 
the server may not be including it in the <lockdiscovery> and/or (b) 
because there may be multiple entries due to shared locks. Of course all 
  of this *could* be explained, but I absolutely do not understand why 
we would want to spend a paragraph describing a work flow that is not 
guaranteed to work, when there's another one which is.

Servers not returning the Lock-Token response header upon successful 
lock creation are buggy and need to be fixed. Is anybody ware of a 
server that currently shows this behaviour?


Best regards, Julian

Received on Wednesday, 16 November 2005 08:29:03 UTC