Log message for revision 76747: Add results from most recent run of litmus WebDAV torture test.
Changed: A Zope/trunk/lib/python/webdav/litmus-results.txt -=- Added: Zope/trunk/lib/python/webdav/litmus-results.txt =================================================================== --- Zope/trunk/lib/python/webdav/litmus-results.txt (rev 0) +++ Zope/trunk/lib/python/webdav/litmus-results.txt 2007-06-17 22:46:33 UTC (rev 76747) @@ -0,0 +1,210 @@ +Zope "litmus" (http://www.webdav.org/neon/litmus/) 0.10.5 test +warnings/skips/failures as of 6/17/2007. + +Command line used: litmus -k http://localhost:8080/ admin admin + +'basic' tests: + + 4. put_get_utf8_segment.. FAIL (PUT of `/litmus/res-%e2%82%ac' + failed: 400 Bad Request) + + Zope considers the id "res-%e2%82%ac" invalid due to the + "bad_id" regex in OFS.ObjectManager, which is consulted whenever + a new object is added to a container through the OFS + objectmanager interface. It's likely possible to replace this + regex with a more permissive one via a monkepatch as necessary. + + 8. delete_fragment....... WARNING: DELETE removed collection resource + with Request-URI including fragment; unsafe + + ZServer strips off the fragment portion of the URL and throws it + away, so we never get a chance to detect if a fragment was sent + in the URL within appserver code. + +'props' tests: + + 17. prophighunicode....... FAIL (PROPPATCH of property with high + unicode value) + + The exception raised by Zope here is: + + 2007-06-17 15:27:02 ERROR Zope.SiteErrorLog + http://localhost:8080/litmus/prop2/PROPPATCH + Traceback (innermost last): + Module ZPublisher.Publish, line 119, in publish + Module ZPublisher.mapply, line 88, in mapply + Module ZPublisher.Publish, line 42, in call_object + Module webdav.Resource, line 315, in PROPPATCH + Module webdav.davcmds, line 190, in __init__ + Module webdav.davcmds, line 226, in parse + Module webdav.xmltools, line 98, in strval + UnicodeEncodeError: 'latin-1' codec can't encode characters in + position 0-1: ordinal not in range(256) + + This is because the webdav.xmltools.Node.strval method attempts + to encode the string representation of the property node to the + 'default' propertysheet encoding, which is assumed to be + 'latin-1'. The value of the received property cannot be encoded + using this encoding. + + 18. propget............... FAIL (No value given for property + {http://webdav.org/neon/litmus/}high-unicode) + + This is because test 17 fails to set a value. + +'locks' tests: + + 15. cond_put.............. SKIPPED + + Zope does not appear to send an Etag in normal responses, which + this test seems to require as a precondition for execution. See + http://www.mnot.net/cache_docs/ for more information about + Etags. + + These tests appear to be skipped for the same reason: + + 16. fail_cond_put......... SKIPPED + 19. complex_cond_put...... SKIPPED + 20. fail_complex_cond_put. SKIPPED + + Zope's webdav package has an webdav.EtagSupport.EtagSupport + class which is inherited by the webdav.Lockable.LockableItem + class, which is in turn inherited by the + webdav.Resource.Resource class, which is in turn inherited by + OFS.SimpleItem.SimpleItem (upon which almost all Zope content is + based), so potentially all Zope content can reasonably easily + generate meaningful ETags in responses. Finding out why it's + not generating them appears to be an archaeology exercise. + + 18. cond_put_corrupt_token FAIL (conditional PUT with invalid + lock-token should fail: 204 No Content) + + I (chrism) haven't been able to fix this without breaking + 32. lock_collection, which is a more important interaction. See + webdav.tests.testResource.TestResource.donttest_dav__simpleifhandler_cond_put_corrupt_token. + + 22. fail_cond_put_unlocked FAIL (conditional PUT with invalid + lock-token should fail: 204 No Content) + + I (chrism) haven't been able to fix this without breaking + 32. lock_collection, which is a more important interaction. See + webdav.tests.testResource.TestResource.donttest_dav__simpleifhandler_fail_cond_put_unlocked. + + 23. lock_shared........... FAIL (LOCK on `/litmus/lockme': 403 + Forbidden) + + Zope does not support locking resources with lockscope 'shared' + (only exclusive locks are supported for any kind of Zope + resource). Litmus could probably do a PROPFIND on the + /litmus/lockme resource and check the <supportedlock> lockscope + in the response before declaring this a failure (class 2 DAV + servers are not required to support shared locks). + + The dependent tests below are skipped due to this failure: + + 24. notowner_modify....... SKIPPED + 25. notowner_lock......... SKIPPED + 26. owner_modify.......... SKIPPED + 27. double_sharedlock..... SKIPPED + 28. notowner_modify....... SKIPPED + 29. notowner_lock......... SKIPPED + 30. unlock................ SKIPPED + + 34. notowner_modify....... WARNING: DELETE failed with 404 not 423 + FAIL (MOVE of locked resource should fail) + + Unknown reasons (not yet investigated). + + 36. indirect_refresh...... FAIL (indirect refresh LOCK on + /litmus/lockcoll/ via /litmus/lockcoll/lockme.txt: 400 Bad + Request) + + Unknown reason (not yet investigated). + +'http' tests: + + 2. expect100............. FAIL (timeout waiting for interim response) + + Unknown reason (not yet investigated). + +additional notes: + + litmus 0.11 times out on several of the lock tests due to some + HTTP-level miscommunication between neon 0.26 and Zope (perhaps, as + I've gathered on the litmus maillist, having to do with neon 0.26's + expectation to use persistent connections, and perhaps due to some + bug in Zope's implementation of same), and this is why litmus + 0.11/neon 0.25 was used to do the testing even though litmus 11.0 + was available. litmus 0.10.5 times out in a similar fashion on the + "http.expect100" test but on none of the lock tests. + +analyses: + + Analysis of what happens during locks 32. lock_collection: + + The first request in this test set is a successful LOCK request + with "Depth: infinity" to /litmus/lockcoll (an existing + newly-created collection): + + LOCK /litmus/lockcoll/ HTTP/1.1 + Depth: infinity + + <?xml version="1.0" encoding="utf-8"?> + <lockinfo xmlns='DAV:'> + <lockscope><exclusive/></lockscope> + <locktype><write/></locktype> + <owner>litmus test suite</owner> + </lockinfo> + + Zope responds to this with a success response like this: + + <?xml version="1.0" encoding="iso-8859-15" ?> + <d:prop xmlns:d="DAV:"> + <d:lockdiscovery> + <d:activelock> + <d:locktype><d:write/></d:locktype> + <d:lockscope><d:exclusive/></d:lockscope> + <d:depth>infinity</d:depth> + <d:owner>litmus test suite</d:owner> + <d:timeout>Second-3600</d:timeout> + <d:locktoken> + <d:href>opaquelocktoken:{olt}</d:href> + </d:locktoken> + </d:activelock> + </d:lockdiscovery> + </d:prop> + + ({olt} in the above quoted response represents an actual valid + lock token, not a literal) + + The next request sent during this test is a conditional PUT + request to /litmus/lockcoll/lockme.txt (which doesn't yet + exist at the time of the request): + + PUT /litmus/lockcoll/lockme.txt HTTP/1.1 + If: <http://localhost:8080/litmus/lockcoll/> (<opaquelocktoken:{olt}) + + The If header in this request specifies that the {olt} locktoken + should be checked against the resource + http://localhost:8080/litmus/lockcoll/ (the collection parent). + + In response to the PUT command, inside Zope, a NullResource + object is created representing /litmus/lockcoll/lockme.txt. + NullResource.PUT determines its parent is locked and so calls + dav__simpleifhandler on the parent (/litmus/lockcoll). This + does not raise an exception due to the fact that the If header + specifies it as the resource being consulted for a lock. + + With the "is the parent locked" guard condition satisfied, + NullResource.PUT continues. It extracts the file body out of the + request and creates a new object based on the file body content + using PUT_factory. It then turns around and sets the new object + into its container and calls newob.PUT(REQUEST, RESPONSE). + + Litmus expects the PUT request to succeed with a 2XX response + (and presumably the new lockme.txt resource should be created + within /litmus/lockcoll). See + http://mailman.webdav.org/pipermail/litmus/2005-August/000169.html + for more rationale about why this is assumed to be "the right + thing". + _______________________________________________ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins