Unbelievable. Microsoft was one of the first places to support WebDAV, and after a little investigation, looks like they've completely changed how they support it--with security implications, and an amazing amount of brokenness...
At Freelock, we've used WebDAV to allow our clients to access to our servers since day 1. FTP is fundamentally unsecure, and as business level hosts, we refuse to allow that. SFTP is a really good option, but it does require us to set up local user accounts on the server and allow a higher level of access--something we would prefer not to do on our shared servers. WebDAV has long been the clear answer to this, supported by every major operating system with no extra add-ons, and also supported by most web development tools natively. That is, until last year, when Microsoft completely changed the way they do WebDAV. It even breaks compatibility with their own Sharepoint software!
Without testing this fully, this appears to be the situation, version by version:
* Windows 98, 2000, XP (does this still work in SP2/3? Dunno):
- Use Internet Explorer. Go to the File -> Open dialog, check the box to open as web folder, enter the WebDAV URL, and open.
This works really well, though if you bookmark it, it will open it as a web page, no longer a web folder.
* Windows XP SP2:
1. Apply a registry hack to enable basic authentication
2. Open Windows Explorer, and go to Tools -> Map Network Drive
3. Enter the path to the drive (you cannot use https unless you have Office installed) and a drive letter to map. Alternatively, use NET USE on the command line.
* Vista:
1. Apply registry hack to enable basic authentication (or set up server to use Digest authentication, and strip domain name out of user credentials)
2. Set up server to not reject requests to anywhere in the path for OPTIONS and PROPFIND requests
Read on for more details.
Microsoft disables basic authentication in Vista and now in Windows XP SP2. To turn it back on, it takes a registry hack:
https://support.microsoft.com/kb/841215
http://www.simple-groupware.de/cms/WebDAV
First of all, it looks like there's a Microsoft fix you can download that makes it work SOMETIMES.
http://kb.iu.edu/data/araf.html
Windows XP only supported SSL-secured webdav if MS Office is installed:
https://www.vistax64.com/vista-general/20684-webdav-windows-vista.html
Also in that thread: instructions for using "net use" to mount a webdav folder--maybe something we can create a batch file for?
Nice instructions, with screenshots:
https://kb.wisc.edu/luwmad/page.php?id=6280
http://www.yale.edu/its/software/win/configuration_instructions/WebDAV-Vista.pdf
Something to try: using backslashes in the URL:
http://www.wensh.net/archive.php/topic/1478.html
Lots of investigation in this thread:
http://w3-org.9356.n7.nabble.com/WebDAV-with-Windows-Vista-tp229694.html
... along with the rather astonishing network trace showing how broken it is...
From the Subversion book: http://svnbook.red-bean.com/en/1.2/svn.webdav.clients.html
Microsoft Web Folders
Microsoft was one of the original backers of the WebDAV specification, and first started shipping a client in Windows 98, known as “Web Folders”. This client was also shipped in Windows NT4 and 2000.
The original Web Folders client was an extension to Explorer, the main GUI program used to browse filesystems. It works well enough. In Windows 98, the feature might need to be explicitly installed if Web Folders aren't already visible inside “My Computer”. In Windows 2000, simply add a new “network place”, enter the URL, and the WebDAV share will pop up for browsing.
With the release of Windows XP, Microsoft started shipping a new implementation of Web Folders, known as the “WebDAV mini-redirector”. The new implementation is a filesystem-level client, allowing WebDAV shares to be mounted as drive letters. Unfortunately, this implementation is incredibly buggy. The client usually tries to convert http URLs (http://host/repos) into UNC share notation (\\host\repos); it also often tries to use Windows Domain authentication to respond to basic-auth HTTP challenges, sending usernames as HOST\username. These interoperability problems are severe and documented in numerous places around the web, to the frustration of many users. Even Greg Stein, the original author of Apache's WebDAV module, recommends against trying to use XP Web Folders against an Apache server.
It turns out that the original “Explorer-only” Web Folders implementation isn't dead in XP, it's just buried. It's still possible to find it by using this technique:
1. Go to 'Network Places'.
2. Add a new network place.
3. When prompted, enter the URL of the repository, but include a port number in the URL. For example, http://host/repos would be entered as http://host:80/repos instead.
4. Respond to any authentication prompts.There are a number of other rumored workarounds to the problems, but none of them seem to work on all versions and patchlevels of Windows XP. In our tests, only the previous algorithm seems to work consistently on every system. The general consensus of the WebDAV community is that you should avoid the new Web Folders implementation and use the old one instead, and that if you need real a real filesystem-level client for Windows XP, then use a third-party program like WebDrive or NetDrive.
A final tip: if you're attempting to use XP Web Folders, make sure you have the absolute latest version from Microsoft. For example, Microsoft released a bug-fixed version in January 2005, available at https://support.microsoft.com/?kbid=892211. In particular, this release is known to fix a bug whereby browsing a DAV share shows an unexpected infinite recursion.
Unbelievable. Of course, this client is the one they dropped from Vista, so now you're really stuck...
WebDrive, NetDrive
Both WebDrive and NetDrive are excellent commercial products which allows a WebDAV share to be attached as drive letters in Windows. We've had nothing but success with these products. At the time of writing, WebDrive can be purchased from South River Technologies (https://southrivertech.com/). NetDrive ships with Netware, is free of charge, and can be found by searching the web for “netdrive.exe”. Though it is freely available online, users are required to have a Netware license. (If any of that sounds odd to you, you're not alone. See this page on Novell's website: http://www.novell.com/coolsolutions/qna/999.html)
Detailed list of versions and broken-ness:
http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html
https://en.wikipedia.org/wiki/WebDAV
Possible clients to try:
EnginSite DataFreeway: http://www.enginsite.com/Download.htm#Freeware (Proprietary, Free)
BitKinex: http://www.sharewareconnection.com/download-bitkinex-ftp-client-from-sharecon.html (Shareware)
WebDrive: http://www.sharewareconnection.com/webdrive.htm (Free evaluation, $59/year)
NetDrive: http://www.sharewareconnection.com/netdrive.htm (Commercial but free)
Server configurations:
It sounds like there are two main new issues to consider when setting up a server for use by the native Vista WebDAV client (if you could call it that):
1. Need to allow WebDAV extensions at the site root for all users--specifically OPTIONS and PROPFIND.
http://forums.techarena.in/vista-help/697569.htm#post2661117
http://www.borlik.net/blog/archives/000157.html
2. Might need to rewrite authentication headers to remove the server or host name from the username. Found a link to a Java servlet configuration that did this--lost it now.
We've been trying to get
We've been trying to get Vista working against our Apache Webdav server with Basic Auth over SSL for over a year. On some systems, mapping a network drive worked but creating a web folder didn't, and vice versa. Even when it worked, it was unreliable, e.g. mapped network drives didn't automatically reconnect on startup, Office 2007 applications could open files, but failed to save them, even though we could drag/replace into an open web folder on the desktop. Since our Windows XP clients worked fine, we assumed the issue was with the MS webdav redirector.
After reading the blog entry above at http://www.borlik.net/blog/archives/000157.html, however, we decided to take a closer look at the apache configuration. After making the three server-side modifications below, Vista now works like a charm.
1. Added 'dav on' to the root folder of the virtual server (the blog entry shows an example.
2. Added to the root folder, and all child folders with unique access restrictions.
3. Gave the apache user read/write access to all files (this was causing the save failures).
Thanks for the pointers and links!
Add new comment