work done for Infrae.

The REQUEST should not accept holds after it has been closed.

o See http://www.zope.org/Collectors/Zope/2333

registered via five:registerPackage.

        errors

      - Collector #2295: Comments in PythonScripts could lead to syntax
        errors

        errors

      - DAV: compatibility with Windows Web Folders restored by adding
        a configuration variable that controls the sending of the
        non-standard MS-Author-Via and Public headers. Thanks for
        PatrickD for the the hard work coming up with an initial
        patch.
        (http://zope.org/Collectors/Zope/1441)

Revert code that fixed litmus cond_put_corrupt_token and fail_cond_put_unlock tests, because the fix broke (the more important) lock_collection test.

Add a description of the current litmus failures in webdav/litmus-results.txt.

Add support for delayed initialization of packages through a _packages_to_initialize list on the Products package

Delay registration of python packages until a moment when a ZODB connection is available http://www.zope.org/Collectors/Zope/2293

        webdav.Resource.dav__simpleifhandler.  If the resource is not
        locked, and a DAV request contains an If header, no token can
        possibly match and we must return a 412 Precondition Failed
        instead of 204 No Content.

        in webdav.Resource.dav__simpleifhandler.  If the resource is
        locked at all, and a DAV request contains an If header, and
        none of the lock tokens present in the header match a lock on
        the resource, we need to return a 423 Locked instead of 204 No
        Content.

        because we returned "412 Precondition Failed" instead of "423
        Locked" when the resource attempting to be moved was itself
        locked.  Fixed by changing Resource.Resource.MOVE to raise the
        correct error.

the wrong thing.

propwformed were failing because Zope did not strip off the
xmlns: attribute attached to XML property values.  We now strip
off all attributes that look like xmlns declarations.

resource hasn't been locked with, we should return an error
instead of a 20X response.  See
http://lists.w3.org/Archives/Public/w3c-dist-auth/2001JanMar/0099.html
for rationale.

Prior to Zope 2.11, we returned a 204 under this circumstance.
We choose do what mod_dav does, which is return a '400 Bad
Request' error.

This was caught by litmus locks.notowner_lock test #10.

of litmus version 10.5 (http://www.webdav.org/neon/litmus/)
expose a bug in Zope propertysheet access via DAV.  If a
proppatch command sets a property with a null xmlns,
e.g. with a PROPPATCH body like:

<?xml version="1.0" encoding="utf-8" ?>
<propertyupdate xmlns="DAV:">
<set>
<prop>
 <nonamespace xmlns="">randomvalue</nonamespace>
</prop>
</set>
</propertyupdate>

When we set properties in the null namespace, Zope turns
around and creates (or finds) a propertysheet with the
xml_namespace of None and sets the value on it.  The
response to a subsequent PROPFIND for the resource will fail
because the XML generated by dav__propstat included a bogus
namespace declaration (xmlns="None").

Fixed by amending OFS.PropertySheets.dav__propstat.