So I am going along implementing RFC 2518 and was Googling for clarification on an item. One of the search results caught my eye because it referenced "WebDAV Batch Methods." I was a bit puzzled by this, because I have read RFC 2518 at least a dozen times now, and have never seen a reference to this phrase.

Did a bit of digging and discovered this on MSDN. I don't understand how Microsoft can have this documentation without once mentioning that these batch methods are entirely a Microsoft concoction. I will not be implementing BCOPY, BDELETE, BMOVE, BPROPFIND and BPROPPATCH.

Now that I have made significant progress in my WebDAV server API implementation, I can post some details.

My goal is to create an API that faithfully implements RFC2518. This RFC outlines the Http/1.1 Extensions that constitute the WebDAV protocol. There are two levels: Level 1, general WebDAV support, and Level 2, locking support. I plan on supporting both levels, but for the 0.xx release will release with Level 1 support only.

I have designed the API so any developer who knows how to code with a .Net language can use the API. Zero knowledge of WebDAV is required. To use the API, a developer would need to:

1) Reference the API assembly from her/his class project.

2) Provide an implementation of abstract classes WebDAVCollection and WebDAVItem. Basically, you have to map your data store collections and items so that when the API requests a collection or an item, it gets one.

3) Provide an implementation of abstract WebDAVAuthentication class.

To put it in use, you have to:

1) Configure IIS to support file extension .davx and have it respond to all verbs (the extension is irrelevant; if you want, you can have it be .foobar, as long as it responds to all verbs).

2) Add a line similar to the following in your web.config:
<add verb="*" path="MyFiles.davx" type="MyCompany.WebDAV, MyCompany.WebDAV" />

3) Create a file with the name used in #2 (i.e. MyFiles.davx). This file can be empty.

With this in place, Windows or Mac clients can natively map a drive letter using http://yourserver/MyFiles.davx as the path. Alternately, they can directly open a resource as a file from applications such as Word, Excel, HomeSite etc.

I have designed the API so each unique data store type on the server, would have an end-point ({something}.davx) and a line in the web.config.

For example, a handler such as DotNetNukeHTML.davx could be placed in the root of a DotNetNuke portal. A user on a Windows or Mac platform could then map a drive letter using http://yourserver/DotNetNukeHTML.davx/NNN where NNN is the DotNetNuke Portal ID. The user would then see a folder structure where each folder corresponds to a DotNetNuke tab. Within each folder are files corresponding to DotNetNuke module instances. Initially I plan on supporting only the HTML and NukeHTML modules so you would only see files for each instance of these modules. You could then open any of the files using Word, HomeSite or any other HTML Editor and edit the file and save it back. Of course, you can also create a new file which will result in a new module instance being added to the page.

This will basically eliminate the need to use a browser-based editor to create/modify portal content. Just use any rich Windows or Mac editors at your disposal.

This is one example. Using the API, you could also allow full file management on the web server, view a mailbox as a collection of EML files, open up a database table in Excel, there is really no limit to the possibilities. As long as you can figure out a way to present your data (any format) as a data stream that represents the file content expected by a WebDAV-enabled desktop app, you can enable native WebDAV access to your app.

Here's an illustration that gives an overview of how things will work:

I am working on implementing a WebDAV server for ASP.Net. Yes, I know this capability is built-into IIS6, but unfortunately, it requires that you enable WebDAV on the server, creating a big security hole. Additionally, the built-in implementation is unable to authenticate against a custom membership provider. In any event, my solution is a drop-in component that instantly enables WebDAV capabilities for any ASP.Net app.

One of the challenges when developing any app that relies on headers for passing commands back and forth (as WebDAV does), is that debugging is quite challenging. I explored several tools to sniff HTTP traffic, including a few that were implemented as ISAPI filters. I found all to be cumbersome and requiring sever-side installation. There are many IE add-ons that do this also, but since I am working with WebDAV, there is no browser in the equation. It's purely traffic between Windows and a WebDAV server. 

I had resorted to logging to a file from within my app, until I chanced upon HTTPLook. Wow! This app is awesome. It not only does exactly what I want, but it also has a simple and elegant U.I. (important to me) and has excellent features such as filtered capture etc.

My WebDAV development has become several orders of magnitude easier, thanks to this tool. And as a bonus, the app comes with a CHM help file containing the entire HTTP spec. Too cool.

Many customers of my File Manager Pro module have asked for the ability to edit documents directly (i.e. click on an edit icon in the file listing in their browser, then edit and save the document). This is easily done for text-based files, and indeed that capability is already implemented. However, for files that require a client-side application, this is not at all simple.

Let's use Microsoft Word as an example. If you click on a Word doc link in your browser, by way of the mime type (or extension as a fall back), the browser is able to determine which application should be launched. It downloads the file to temp storage and then passes on the location to the app after launching it. Any changes made to this document are made to the copy in temp storage and have no bearing on the original file on the web server.

To facilitate the editing of documents on web servers, both server and client must support WebDAV (Web Distributed Authoring and Versioning), a protocol that extends HTTP by defining standards for web document authoring, versioning and publishing. IIS5 and IIS6 natively support WebDAV (although the capability is not on by default.). Windows XP and Mac OS X natively support the ability to map/mount a WebDAV collection as a virtual drive. All Office apps, most Adobe apps, and many other popular applications support the ability to transparently work with documents using the WebDAV protocol. So what's the problem?

For servers on an Intranet, it is easy to enable WebDAV and create an easy to use shared document area. But then again, on an Intranet, why bother when you could have a shared drive. In a hosted scenario, WebDAV is much more difficult to implement due to the security concerns it poses. Currently, IIS does not provide a way to enable/disable WebDAV on a per web basis. So if a hosting provider were to enable WebDAV it would potentially compromise all websites on the server that were not properly secured. For this reason, WebDAV support in hosted scenarios is almost non-existent.

Also non-existent (as far as my Googling indicates), is a "server" API for a custom WebDAV implementation using ASP.Net. There are many client implementations, but if you want to be able to have WebDAV clients access a database-driven document repository, for example, you are on your own. This brings us back to File Manager Pro.

I was quite intrigued by everything WebDAV had to offer and so started doing some testing. I was pleased to find after a few hours of coding that it is possible to write a custom WebDAV server that works on ASP.Net. And so that is precisely what I am going to do. I am going to implement this as a generic API first and then use the API to add document authoring and versioning capabilities to File Manager Pro.

So far, I have tested getting a directory listing and editing a document. I have not implemented saving it, but I know it will work because my IIS logs show the request coming in with the right content.

This is quite exciting because it opens up File Manager Pro, and indeed DNN, to a whole new level of document collaboration. I am quite interested to see how this API may be used in different DNN modules in the future.