Microsoft Windows information

Connecting with Windows Vista

1. Open 'Computer' from your start menu or desktop
2. Open the 'Map network drive' wizard
3. Enter the full http:// address to your webdav installation

Note: You may need to install Software Update for Web Folders (KB907306) to avoid the following error: "The folder you entered does not appear to be valid".

Connecting for Windows XP / IE 6

1. Open up Internet Explorer
2. Press File, Open and fill in the full url
3. Check the "Open as Web Folder" setting
4. Press Ok

Implementor notes

Microsofts windows' WebDAV implementation requires the WebDAV service to sit at the root of a domainname. There's no way you can connect to a url deeper in the WebDAV structure, because it will traverse every part of the path and make PROPFIND requests. So you have to make absolutely sure you have SabreDAV installed on a root url. If you are using apache, you can use mod_rewrite to map every single request to your WebDAV server, for example:

RewriteEngine On
RewriteRule ^/(.*)$ /server.php [L]

Windows XP has even more quirks, and will treat the root of your WebDAV server as if it was connecting to an SMB server. You'll notice that when you're connecting, you will only see directories the root folder and they have icons similar to windows shared folders. You can only really perform operations within subdirectories on your root. So, in short:

If you want to enable Windows clients to connect to your WebDAV share, make sure it is installed on the root of your domain, and make sure all operations happen within sub-directories of your share. The easiest way to do this is by simply creating a single top-level /dav/ directory

Lastly, if you add in HTTP authentication, make sure you don't do this for OPTIONS requests. This will make Windows fail to connect and it's safe to not ask for authentication on OPTIONS Not sure how I triggered this, but it works fine for me now.

Mapping to a drive letter

Mapping to a drive letter is possible, and quite benefitial, as it integrates directly into your operation system. Normally connecting to WebDAV would not allow you to edit files directly, but it will only allow you to drag and drop from and into a webdav folder.

There are some restrictions to this however:

• You absolutely need to connect to a directory on your webdav service. Connecting directly to the root of a domain will not work
• Basic Auth will not work by default, using either no authentication at all or using Digest authentication will work. See Authentication

You can then map a network drive by using the 'Map network drive' menu in Explorer, or type:

net use * http://example.org/dav/

Protocol details

• User agents:
• Vista: Microsoft-WebDAV-MiniRedir/6.0.6000
• XP: Microsoft-WebDAV-MiniRedir/5.1.2600 and Microsoft Data Access Internet Publishing Provider DAV 1.1 and Microsoft Data Access Internet Publishing Provider Cache Manager
• Vista doesn't include a request body when making PROPFIND requests
• Windows Vista is a lot less broken
• Windows XP expects the HTTP response header when making an OPTIONS request : MS-Author-Via: DAV
• Windows XP does not like whitespace in xml body responses for PROPPATCH. Make sure you send back the xml response with no whitespace

Translate

Windows sends along a 'Translate: f' header along with every request. The idea is that if you for example access a php file, and translate is set to 'f', you would retrieve the php source file. If translate is set to 't', the php file should be run and the output should be returned.

This is currently irrelevant to SabreDAV. I don't know how to trigger 'Translate: t' either, and i'd recommend against doing anything with it.

Creating new files

Windows seems to perform the following actions when doing a PUT request:

1. Create an empty file using PUT
2. Lock the newly created file
3. PUT on the same file again with the actual file body
4. A PROPPATCH request

Properties

Windows XP requires a special format for the getlastmodified dav property in the propfind response. An example is :

<d:getlastmodified xmlns:b="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/" b:dt="dateTime.rfc1123">Sat, 26 Apr 2008 18:00:18 -0400</d:getlastmodified>

Windows XP requests the following webdav properties when making requests:

• name
• parentname
• href
• ishidden
• iscollection
• isreadonly
• getcontenttype
• contentclass
• getcontentlanguage
• creationdate
• lastaccessed
• getlastmodified
• getcontentlength
• resourcetype
• isstructureddocument
• defaultdocument
• displayname
• isroot

Windows (XP and Vista) introduces the following properties under the "urn:schemas-microsoft-com:" xml namespace:

• Win32CreationTime (example: Sat, 26 Apr 2008 20:38:50 GMT)
• Win32LastAccessTime (same format)
• Win32FileAttributes (example: 00002020) indicates the classic MS-DOS properties, such as 'read only, hidden, archive, system' and a couple of newer ones. Haven't located detailed docs yet

Authentication

HTTP Digest is support across the board. HTTP Basic auth can be used directly from within IE, but will not work by default if you're attempting to map a share to a drive letter, unless WebDAV is used over SSL.

Basic auth can be enabled if the following registry change is made:

• Create a new registry key called HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\UseBasicAuth and
• Set the value to '1' (without quotes).

It was also reported that in certain cases HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\BasicAuthLevel needs to be set to 2

• KB928692
• KB841215

Save the following to a .reg file and open it to simplify patching the registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters]
"UseBasicAuth"=dword:00000001
"BasicAuthLevel"=dword:00000002

In some cases Windows will incorrectly prepend the NT domain to the username with two backslashes. Example:

MYDOMAIN\\username

The workaround for this is making the user go through all the login prompts (removing the NT domain), it will succeed after a while. It would also be possible to automatically detect and strip out these usernames but that could be problematic in relation to HTTP digest authentication.