Add results from most recent run of litmus WebDAV torture test.

lib/python/webdav/litmus-results.txt

+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".
+