Subject: Microsoft Mini-Redirector Bug with respect to handling DAV:href

From: Julian Reschke <[email-masked]>
Date: Sat, 02 Jun 2012 11:38:34 +0200

Hi there,

reporting here so it get's archived:

Version: Microsoft-WebDAV-MiniRedir/6.1.7601

Problem: client is doing a PROPFIND request without payload, thus 
defaulting to DAV:allprop.

Server returns a custom property than *contains* a DAV:href child 
element, like that:

<D:response>
   <D:href>/foo/bar.txt</D:href>
   <D:propstat>
     <D:prop>
       <D:displayname>bar.txt</D:displayname>
       <D:creationdate>2012-06-01T12:52:57Z</D:creationdate>
       <D:resourcetype/>
       <D:lockdiscovery/>
       <D:getcontenttype>text/plain; charset=UTF-8</D:getcontenttype>
       <C:linked-from xmlns:C="http://example.com/ns">
         <D:href>/qux</D:href>
       </C:linked-from>
       <D:getetag>"7248-1338555179558"</D:getetag>
       <D:getlastmodified>Fri, 01 Jun 2012 12:52:59 GMT</D:getlastmodified>
       <D:supportedlock>
         <D:lockentry>
           <D:lockscope><D:exclusive/></D:lockscope>
           <D:locktype><D:write/></D:locktype>
         </D:lockentry>
       </D:supportedlock>
       <D:getcontentlength>7248</D:getcontentlength>
     </D:prop>
     <D:status>HTTP/1.1 200 OK</D:status>
   </D:propstat>
</D:response>

So the response element contains a top-level DAV:href for the URI for of 
the resource:

   <D:href>/foo/bar.txt</D:href>

...but also a nested...

       <C:linked-from xmlns:C="http://example.com/ns">
         <D:href>/qux</D:href>
       </C:linked-from>

inside D:propstat/D:prop.

The client apparently gets confused and uses the second DAV:href 
element; causing a wrong name to be displayed (and likely the wrong 
resource to be used when opened).

Best regards, Julian