1. 18 Jul, 2007 1 commit
  2. 12 Jul, 2007 2 commits
  3. 10 Jul, 2007 1 commit
  4. 05 Jul, 2007 1 commit
  5. 02 Jul, 2007 1 commit
  6. 01 Jul, 2007 2 commits
  7. 29 Jun, 2007 1 commit
  8. 26 Jun, 2007 2 commits
  9. 25 Jun, 2007 2 commits
  10. 24 Jun, 2007 1 commit
  11. 23 Jun, 2007 8 commits
  12. 18 Jun, 2007 2 commits
    • Sidnei da Silva's avatar
      · e28f818f
      Sidnei da Silva authored
            - 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)
      e28f818f
    • Wichert Akkerman's avatar
      Fix typo · 957dd598
      Wichert Akkerman authored
      957dd598
  13. 17 Jun, 2007 11 commits
  14. 16 Jun, 2007 2 commits
    • Chris McDonough's avatar
      When attempting to unlock a resource with a token that the · ccc4a377
      Chris McDonough authored
      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.
      ccc4a377
    • Chris McDonough's avatar
      Tests 15 (propnullns) and 16 (propget) from the props suite · 0e9e7a53
      Chris McDonough authored
      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.
      0e9e7a53
  15. 10 Jun, 2007 1 commit
  16. 09 Jun, 2007 2 commits