I performed a PROPPATCH followed by a PROPFIND, and mod_dav has corrupted a property attribute namespace, as you can see from the log below. Specifically, the attribute rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil" has been changed to dc:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil". This means that mod_dav is completely broken with regard to correct WebDAV property storage, and has essentially shot down my project until I can complete writing my own WebDAV server. Logged communication is below. Garret PROPFIND /marmoxdemo/balcony_sunglasses.jpg HTTP/1.1 depth: 0 content-length: (removed) host: dav.globalmentor.com authorization: BASIC (removed) <?xml version="1.0" encoding="UTF-8"?> <D:propfind xmlns:D="DAV:"> <D:allprop /> </D:propfind> HTTP/1.1 207 Multi-Status Date: Tue, 20 Mar 2007 02:40:34 GMT Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.8a DAV/2 SVN/1.5.0-dev PHP/5.1.2 mod_jk/1.2.15 Content-Length: 1083 Content-Type: text/xml; charset="utf-8" <?xml version="1.0" encoding="utf-8"?> <D:multistatus xmlns:D="DAV:" xmlns:ns0="DAV:"> <D:response xmlns:ns0="DAV:" xmlns:ns1="http://purl.org/dc/elements/1.1/" xmlns:lp1="DAV:" xmlns:lp3="http://subversion.tigris.org/xmlns/dav/" xmlns:lp2="http://apache.org/dav/props/"> <D:href>/marmoxdemo/balcony_sunglasses.jpg</D:href> <D:propstat> <D:prop> <ns1:title>Balcony Sunglasses</ns1:title> <lp1:resourcetype/> <lp1:creationdate>2007-03-17T20:39:47Z</lp1:creationdate> <lp1:getcontentlength>48077</lp1:getcontentlength> <lp1:getlastmodified>Sat, 17 Mar 2007 20:39:47 GMT</lp1:getlastmodified> <lp1:getetag>"191019e-bbcd-5b5a6ac0"</lp1:getetag> <lp2:executable>F</lp2:executable> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> <D:lockdiscovery/> <D:getcontenttype>image/jpeg</D:getcontenttype> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus> PROPPATCH /marmoxdemo/balcony_sunglasses.jpg HTTP/1.1 content-length: (removed) host: dav.globalmentor.com authorization: BASIC (removed) <?xml version="1.0" encoding="UTF-8"?> <D:propertyupdate xmlns:D="DAV:" xmlns:marmot="http://globalmentor.com/namespaces/marmot#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <D:set> <D:prop> <marmot:access> <marmot:access> <marmot:CustomAccess> <marmot:rules> <rdf:List> <rdf:first> <marmot:AccessRule> <marmot:principal rdf:resource="mailto:*@*" /> <marmot:allow> <marmot:ReadPermission /> </marmot:allow> <marmot:allow> <marmot:WritePermission /> </marmot:allow> </marmot:AccessRule> </rdf:first> <rdf:rest> <rdf:List rdf:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil" /> </rdf:rest> </rdf:List> </marmot:rules> </marmot:CustomAccess> </marmot:access> </marmot:access> </D:prop> </D:set> </D:propertyupdate> HTTP/1.1 207 Multi-Status Date: Tue, 20 Mar 2007 02:40:49 GMT Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.8a DAV/2 SVN/1.5.0-dev PHP/5.1.2 mod_jk/1.2.15 Content-Length: 392 Content-Type: text/xml; charset="utf-8" <?xml version="1.0" encoding="utf-8"?> <D:multistatus xmlns:D="DAV:" xmlns:ns2="http://globalmentor.com/namespaces/marmot#" xmlns:ns1="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ns0="DAV:"> <D:response> <D:href>/marmoxdemo/balcony_sunglasses.jpg</D:href> <D:propstat> <D:prop> <ns2:access/> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus> PROPFIND /marmoxdemo/balcony_sunglasses.jpg HTTP/1.1 depth: 0 content-length: (removed) host: dav.globalmentor.com authorization: BASIC (removed) <?xml version="1.0" encoding="UTF-8"?> <D:propfind xmlns:D="DAV:"> <D:allprop /> </D:propfind> HTTP/1.1 207 Multi-Status Date: Tue, 20 Mar 2007 02:40:49 GMT Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.8a DAV/2 SVN/1.5.0-dev PHP/5.1.2 mod_jk/1.2.15 Content-Length: 1805 Content-Type: text/xml; charset="utf-8" <?xml version="1.0" encoding="utf-8"?> <D:multistatus xmlns:D="DAV:" xmlns:ns0="DAV:"> <D:response xmlns:ns0="DAV:" xmlns:ns1="http://purl.org/dc/elements/1.1/" xmlns:ns2="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ns3="http://globalmentor.com/namespaces/marmot#" xmlns:lp1="DAV:" xmlns:lp3="http://subversion.tigris.org/xmlns/dav/" xmlns:lp2="http://apache.org/dav/props/"> <D:href>/marmoxdemo/balcony_sunglasses.jpg</D:href> <D:propstat> <D:prop> <ns1:title>Balcony Sunglasses</ns1:title> <ns3:access> <ns3:access> <ns3:CustomAccess> <ns3:rules> <ns2:List> <ns2:first> <ns3:AccessRule> <ns3:principal ns1:resource="mailto:*@*"/> <ns3:allow> <ns3:ReadPermission/> </ns3:allow> <ns3:allow> <ns3:WritePermission/> </ns3:allow> </ns3:AccessRule> </ns2:first> <ns2:rest> <ns2:List ns1:about="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/> </ns2:rest> </ns2:List> </ns3:rules> </ns3:CustomAccess> </ns3:access> </ns3:access> <lp1:resourcetype/> <lp1:creationdate>2007-03-17T20:39:47Z</lp1:creationdate> <lp1:getcontentlength>48077</lp1:getcontentlength> <lp1:getlastmodified>Sat, 17 Mar 2007 20:39:47 GMT</lp1:getlastmodified> <lp1:getetag>"191019e-bbcd-5b5a6ac0"</lp1:getetag> <lp2:executable>F</lp2:executable> <D:supportedlock> <D:lockentry> <D:lockscope><D:exclusive/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> <D:lockentry> <D:lockscope><D:shared/></D:lockscope> <D:locktype><D:write/></D:locktype> </D:lockentry> </D:supportedlock> <D:lockdiscovery/> <D:getcontenttype>image/jpeg</D:getcontenttype> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus>
Hmmm... so does no one care to look into a blocker bug that breaks proper operation of the most popular WebDAV server in the world?
Thanks for the repro case. This is a little tricky to track down, please have a little patience.
Created attachment 19799 [details] fix for apr-util attribute namespace handling cd srclib/apr-util patch -p0 < /path/to/this/diff Fun bug, this has existed since the beginning of time!
Thank you so much for addressing this, Joe. Essentially every mod_dav server out there has been broken for the past seven years or so, huh? This apparently means that no one is really using complex WebDAV properties with mod_dav. How long should it be before this is bundled with an Apache httpd release?
Yes, the bug exists in the mod_dav 1.0.x releases too. The bug is in the APR-util library, so it will be pulled into a future httpd release once there is a new APR-util release which includes the fix. This is committed now to the trunk, and also to the APR-util 1.2.x branch: http://svn.apache.org/viewvc?view=rev&rev=522630 http://svn.apache.org/viewvc?view=rev&rev=522631 For the record: the repro case for this is actually slightly more complicated than given; it's the fact that there is a stored namespace prefix for the resource (in this case http://purl.org/dc/elements/1.1/) which isn't actually used in the response. And the ordering in which the namespace prefixes are stored matters too. Again: thanks for the report.
Woo hoo---it works! I've just verified that the provided patch fixes Apache httpd mod_dav 2.2.4. Now, can you just turn on that auto-update push-patch feature that automatically updates the current installed base of Apache-based WebDAV servers around the world so that my client can work with them? :( But thanks again for fixing this, Joe! (Hey, just another decade of propagation and I won't have to code special cases for IE6 anymore, either! ;) )