[Zope-Checkins]
SVN: Zope/trunk/lib/python/webdav/litmus-results.txt
Add results from most recent run of litmus WebDAV torture test.
Chris McDonough
chrism at plope.com
Sun Jun 17 18:46:34 EDT 2007
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".
+
More information about the Zope-Checkins
mailing list