First of all, this is the litmus test reports for locks:
0. init.................. pass
1. begin................. pass
2. options............... pass
3. precond............... pass
4. init_locks............ pass
5. put................... pass
6. lock_excl............. pass
7. discover.............. pass
8. notowner_modify....... pass
9. notowner_lock......... pass
10. owner_modify.......... pass
11. notowner_modify....... WARNING: MOVE failed with 412 not 423
...................... pass (with 1 warning)
12. notowner_lock......... pass
13. copy.................. pass
14. cond_put.............. pass
15. fail_cond_put......... WARNING: PUT failed with 423 not 412
...................... pass (with 1 warning)
16. cond_put_with_not..... pass
17. cond_put_corrupt_token pass
18. complex_cond_put...... pass
19. fail_complex_cond_put. FAIL (PUT with complex bogus conditional should fail with 412: 204 No Content)
20. unlock................ pass
21. lock_shared........... pass
22. notowner_modify....... WARNING: MOVE failed with 412 not 423
...................... pass (with 1 warning)
23. notowner_lock......... pass
24. owner_modify.......... pass
25. double_sharedlock..... pass
26. notowner_modify....... WARNING: MOVE failed with 412 not 423
...................... pass (with 1 warning)
27. notowner_lock......... pass
28. unlock................ pass
29. finish................ pass
<- summary for `locks': of 30 tests run: 29 passed, 1 failed. 96.7%
-> 4 warnings were issued.
I see three things:
1) notowner_modify: I've looked into the code and it seems that during COPY/MOVE Slide checks for sourceUri to be locked but doesn't care about the destinationUri. I think this part needs some more thinking as the warnings identify a potentially defective implementation and I think it's the case.
2) fail_cond_put: this warning is a simptom of a bigger problem (see below)
3) fail_complex_cond_put: here slide fails to identify a bogus conditional. The If: header is
If: (<opaquelocktoken:69e926f87b2a7490eb7a8e3a85ed5072> [ff9fe5edd40d4d00de960598b6f7e424]) (Not <DAV:no-lock> [ff9fe5edd40d4d00de960598b6f7e424])
and the code that should parse this is (in class AbstractWebdavMethod)
private List extractLockTokens(String hStr) {
List result = new ArrayList();
int pos = hStr.indexOf(S_LOCK_TOKEN);
int endPos = -1;
int offset = S_LOCK_TOKEN.length();
String lockToken = null; while (pos != -1) {
endPos = hStr.indexOf('>', pos + offset);
if (endPos == -1) {
lockToken = hStr;
endPos = hStr.length();
} else {
lockToken = hStr.substring(pos + offset, endPos);
} slideToken.addLockToken(lockToken);
result.add( lockToken );
pos = hStr.indexOf(S_LOCK_TOKEN, endPos);
}
return result;
}while the full BN notation of the If: header (from the WebDAV spec) is:
If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
No-tag-list = List
Tagged-list = Resource 1*List
Resource = Coded-URL
List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
State-token = Coded-URL
Coded-URL = "<" absoluteURI ">"It seems to me that Slide is blatantly ignoring the complex consitionals in locking, or am I missing something?
- o -
I also found out something about locking that even the Litmus tests fails to address: the way Slide treats the "dav:owner" element is IMHO wrong.
Look at this trace:
LOCK /files/Untitled.txt HTTP/1.1 User-Agent: WebDAVFS/1.2.5 (01258000) Darwin/7.0.0 (Power Macintosh) Accept: */* Host: localhost:10000 Depth: 0 Timeout: Second-600 Content-Type: text/xml; charset="utf-8" Content-Length: 213
<?xml version="1.0" encoding="utf-8" ?> <D:lockinfo xmlns:D="DAV:"> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> <D:owner> <D:href>default-owner</D:href> </D:owner> </D:lockinfo>
HTTP/1.1 200 OK Date: Thu, 13 Nov 2003 15:05:33 GMT Server: Jetty/4.2.14rc1 (Mac OS X/10.3.1 ppc java/1.4.2_01) Set-Cookie: JSESSIONID=3quvhr0cbv7p8;path=/ Content-Type: text/xml; charset="UTF-8" Lock-Token: <opaquelocktoken:21d054f57d7683f25eb5e1332930974f>
<?xml version="1.0" encoding="UTF-8"?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:locktype>
<D:write />
</D:locktype>
<D:lockscope>
<D:exclusive />
</D:lockscope>
<D:depth>0</D:depth>
<D:owner><![CDATA[ <D:href xmlns:D="DAV:">default-owner</D:href> ]]></D:owner>
<D:timeout>Second-599</D:timeout>
<D:locktoken>
<D:href>opaquelocktoken:21d054f57d7683f25eb5e1332930974f</D:href>
</D:locktoken>
<D:principal-URL>
<D:href>/users</D:href>
</D:principal-URL>
</D:activelock>
</D:lockdiscovery>
</D:prop>
The webdav DTD says that the <D:owner> is allowed to contain ANY element and, as a client, I would expect the DOM nodes placed there to be "guaranteed" as the indication of ownership. Slide, insted, treates the owner information as the xml representation of the tree, as identified by the following method in the class LockMethod:
private void parseOwner(Element ownerElement) {
if (ownerElement == null) {
lockInfo_lockOwner = DEFAULT_LOCK_OWNER;
return;
}StringWriter stringWriter = new StringWriter();
XMLOutputter xmlOutputter = new XMLOutputter();
try {
xmlOutputter.outputElementContent(ownerElement, stringWriter);
}
catch (IOException e) {
// this should not happen since we do no "real" I/O but
// only print to a PrintWriter
e.printStackTrace();
}
lockInfo_lockOwner = stringWriter.toString();
if (lockInfo_lockOwner.length() == 0) {
lockInfo_lockOwner = DEFAULT_LOCK_OWNER;
}
}where the owner element is serialized into a String!
The Owner is not a string but a document fragment, a JDOM Element, if you want, and treating it as a string makes clients sensible to the owner tag fail (in fact Slide doesn't work with macosx webdavfs)
Any suggestions/comments?
-- Stefano.
smime.p7s
Description: S/MIME cryptographic signature
