- From: Julian Reschke <julian.reschke@gmx.de>
- Date: 2012年6月02日 11:38:34 +0200
- To: WebDAV <w3c-dist-auth@w3.org>
- Message-ID: <4FC9DF1A.6030609@gmx.de>
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月01日T12: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>2012年6月01日 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
Received on Saturday, 2 June 2012 09:39:04 UTC