Roland Porath wrote:
...
My theory now is that some clients (i.e cadaver) do some caching and
remember the locktokens of the resources that were locked by themselves.
> ...
Actually clients are *expected* to remember the lock tokens they obtained.
This is consistent with behavior i have observed so far:
Dav Explorer: can lock, can't unlock anything (=> no caching)
Cadaver: can lock, can unlock files that i locked in the same session (=>
transient caching)
WebFolders: only kidding.
As a matter of fact, the WebFolder client stack does locking in some
cases (for instance, when opening a document using Office).
The Lock request looks like this
LOCK
/jackrabbit-webapp-1.4/repository/default/SmartRepository/files/Demonstratio
n/locktest/asdf.txt HTTP/1.1
Host: 127.0.0.1:5000
User-Agent: cadaver/0.22.2 neon/0.24.6
Connection: TE
TE: trailers
Content-Length: 203
Content-Type: application/xml
Depth: infinity
Authorization: Basic QWRtaW5pc3RyYXRvcjpmcmVlLkRPTQ==
<?xml version="1.0" encoding="utf-8"?>
<lockinfo xmlns='DAV:'>
<lockscope><exclusive/></lockscope>
<locktype><write/></locktype><owner><href>mailto:[EMAIL PROTECTED]</href
</owner>
</lockinfo>
It generates this response:
HTTP/1.1 200 OK
Lock-Token: <6332dc3f-df44-44a5-adbb-980c7edd3c8c-D>
Nit: the lock token should use URI format. That's (IMHO) a bug in the
Jackrabbit WebDAV layer.
Content-Type: text/xml;charset=UTF-8
Content-Length: 389
Date: Wed, 30 Jan 2008 05:13:53 GMT
Server: Apache-Coyote/1.1
<?xml version="1.0" encoding="UTF-8"?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:lockscope>
<D:exclusive/>
</D:lockscope>
<D:locktype>
<D:write/>
</D:locktype>
<D:depth>infinity
</D:depth>
<D:timeout>Second-2147483
</D:timeout>
<D:owner>Administrator
</D:owner>
<D:locktoken>
<D:href>6332dc3f-df44-44a5-adbb-980c7edd3c8c-D
</D:href>
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
so it seems like the token gets generated but not added to the lookdiscovery
propery
It is there, isn't it.
Is it possible to change that behavior??
What's not there is the original contents of the owner element; and this
is a known issue: some WebDAV clients expect that they can the lock will
persist the information they passed in there, and JCR can't do it.
BR, Julian
