My WebDAV with ASP.NET post has proved to be very popular and gets me emails, so I figured I’d share some more tidbits that I’ve picked up along the way.
What do you learn when you write your own server to implement a standard protocol? Well you learn that protocols share a lot in common with legal contracts. People interpret them in different ways, often in the way that is most advantageous to what they are doing. In writing a WebDAV server, I’ve found out a lot more about Windows than I think I ever wanted to know. I figured I’d write down some of that stuff so that I could remember it, and maybe someone out there on the internet will find it useful as well.
There is not 1 WebDAV for Windows
You can’t really say Microsoft Windows supports WebDAV and think of a monolithic chunk of code that everything uses to talk WebDAV. Windows Explorer uses what’s called the Mini-Redirector. The min-redirector allows you to map a WebDAV location to a Drive letter the same as if you were using a Windows File Sharing/SMB/CIFS share. The mini-redirector has some limitations though.
- No support for HTTPS
- No support for declared ports (http://example.com:8080/path)
- No support for LOCK and UNLOCK commands
There is also a system called Web Folders. Web Folders is the WebDAV implementation for Microsoft Office products. Web Folders supports all of the things that the Mini-Redirector doesn’t, including SSL, file locking, etc.
Right now, you might find yourself asking: “If there are two implementations and one is really limited and one is more featured, then why not just replace the worse version with the better?”. Yeah, I asked the same question and don’t know the answer.
When you map a WebDAV drive in Windows and want to open a Microsoft Office document, you get the distinct pleasure of using both WebDAV implementations. The Mini-Redirector asks the server for the file and once it gets it it opens Office and then Office re-asks the server for the same file again after doing some server discovery and file locking. The hand-off means that Office has to re-authenticate if your WebDAV server uses Digest Authentication, so you get to see a login dialog again. What fun!?
Office uses the OPTIONS command do to Server discovery. Server discovery is basically the process of trying to figure out what kind of server it is and what protocols it supports.
The Office Web Folders always requests OPTIONS from the root (/) of the web server making a horrible assumption that any any server that supports WebDAV must support all the way to the root of the server.
Often when you are allowing users to manipulate files and folders across the internet you might want to use some form of authentication. Digest Authentication is more secure than Basic Authentication which sends the user name and password in plain-text form, so it is a good choice for authentication if you are not going to use a secure (HTTPS) connection. There’s only one small problem with this. There is a bug in the Web Folders implementation so it will not send Authentication headers on OPTIONS requests. That means you have to return an OPTIONS response regardless of what lives at a URL or whether a user is authenticated or they can’t properly open Office documents.
The Office Web Folders support does not just do WebDAV, it can also use Front Page Extensions. Since Front Page is a Microsoft proprietary product, Office prefers to use Front Page over WebDAV. In fact, it prefers it so much, that one of the only ways to get Office to use WebDAV is to use a custom header in OPTIONS requests: MS-Author-Via: DAV
The MS-Author-Via header tells Office that you don’t care how bad it wants to try Front Page, just use WebDAV.
Some Other Resources
Web Folder Client Issues:
WebDAV Reference Book:
WebDAV: Next-Generation Collaborative Web Authoring by Lisa Dusseault