Why is it so hard to get WebDAV to work? Those of you who’ve tried to get this to work know this is quite a challenge. And there are even some who’ve given up on this. And that’s a pity as it can add so much to the experience of DMX. I mean: drag and drop and online editing. Too good to be true.
In this post I’ll try to give some more background info about WebDAV and hopefully you’ll understand better why this is technically difficult to set up and how to approach this when you’re trying to get it to work.
So what exactly is WebDAV
Well, in full it means Web Distributed Authoring and Versioning. And it was originally designed to help people edit online resources like web pages. So you could load an HTML file in an editor and save it back to the server, without having to copy them back and forth by FTP (the most common alternative). It was kind of Web 1.9. Since the phrase “web 2.0” is widely regarded as the web where contributions of users was added to the mix, you could say this was the forerunner. A non-technical person could easily edit a web page. Much like the goal of Microsoft’s FrontPage (I know people that still use this, by the way).
The way this would all work is over HTTP. HTTP is the protocol used by our computers to talk to web servers. For instance, your PC could issue the following command:
GET / HTTP/1.1
To the server “www.google.com” you get Google’s home page (the single forward “/” means: get me your default page) in return. What is returned is in HTML. So it’s good to just keep these things apart: HTTP and HTML. HTTP is a set of agreements that govern how your PC should speak to a server to retrieve content. HTML is the format in which the response is written.
Now the “GET xyz” syntax is fairly simple and is used to get everything from the web server. So not just an HTML file, but also images, css files, javascript files, etc. All these items can be requested through HTTP from a server. As you know ASP.NET pages have an extension .aspx. So when your browser asks for “/default.aspx” the server, where IIS is in charge of this, invokes ASP.NET and begins processing the aspx file. All this with “GET”. We call “GET” the “verb”, for obvious reasons. So the HTTP Verb of your request is “GET”.
This is where the rubber meets the road. You see, the GET verb was but one verb defined by the working group in charge of HTTP. They also defined POST to handle uploads from browsers (when you submit a form on the web, the browser emits a POST to the web server). And this could be extended further. So the WebDAV group came along and said: hey, we’d like to add a couple of verbs to this to facilitate online document editing. So the following verbs are used by WebDAV: GET (obviously to get a document), PUT (to write it back), PROPFIND (get properties of a document), PROPPATCH (set properties of a document), MKCOL (create a new folder), COPY, MOVE, LOCK (prevent other users from editing a document) and UNLOCK.
In addition the specifications for WebDAV make use of the request and response bodies over HTTP. Specifically the content, besides sometimes being the document itself, is often an XML blob that holds relevant data. If a WebDAV client asks for the contents of a folder, then the response is an XML blob with details of all items in that folder. If it asks for properties using PROPFIND, then the properties are returned in an XML blob. Etc.
So WebDAV is an extension of the HTTP protocol. And it allows various clients to talk to a variety of servers. As long as both parties stick to the protocol, things should go smoothly. And we should just pause and reread that statement as you need to keep this in mind. WebDAV is a protocol. And you need both a WebDAV client and a WebDAV server to have a meaningful WebDAV exchange. As you know DMX includes a WebDAV server. So what are WebDAV clients? Well, Windows itself is a WebDAV client. You can mount a WebDAV folder as a drive in Windows. But MS Office is also a WebDAV client. Word “knows how to speak WebDAV”. But Notepad, for instance, does not. So whatever you tweak or do, you’ll never get Notepad to be able to edit a document over WebDAV.
Now that we know what WebDAV is let’s examine some of the complexities this creates for server admins.
The WebDAV server
DMX includes a WebDAV server. That is: it includes code that can “speak WebDAV”. But DMX is a module inside DotNetNuke. And DotNetNuke is but an ASP.NET web application running under IIS. And this is where things get complicated. You see, when the client issues an HTTP command, this command has to be “routed” to the right place. This routing begins at the client side. It traverses the internet. This part is out of our hands, but luckily this is never an issue with WebDAV. And then it arrives at the web server. At that point IIS is in charge. It needs to decide where the request should go. And it does that based on (1) the verb and (2) the “shape” of the request resource (i.e. url). The meaning of “shape” will become clearer as we continue.
Anatomy of a web request
The diagram below attempts to show what happens when a web request reaches IIS:
As you can see it passes through several so-called “modules” and ends up in one “handler”. These modules are not DNN modules, but “Http Modules”. If you’d like to know more about this then please read my posts about modules here and handlers here. What we will be focusing on here are handlers. A handler is a component that “knows what to do” with the request and is asked to generate the appropriate response. Here we need to look at the point where IIS decides which handler it should choose. This is governed by the web.config (IIS 7+). Basically, IIS looks at each handler in turn (this is why the order in which they appear in the web.config is significant) and when the url matches the pattern described it will pass the request to that handler. The ensemble of a correct DNS registration of your server, correct hookup to the internet, the correct server configuration (firewall etc) and finally the correct entries in the web.config ensure correct “routing”. It is not unlike how you rely on various telephone exchanges and secretaries to make sure your call to request support on your mobile phone arrives at a technician at the mobile phone operator that knows how to help you. You rely on proper routing.
And faulty routing is one of the leading causes of failure of WebDAV. And why can’t I solve that for you? Well, that is because DMX is but a DNN module and is subject to a certain amount of “isolation”. Meaning: it is allowed to do whatever it wants within a strict set of boundaries. These boundaries are governed by DNN and by the server. There is no way that DMX could access the firewall settings of your server, for instance. And that’s reassuring. But it does pose limits on what the module can do to automate and help routing. What DMX *does* do is to add the correct routes to the web.config. That it can do. But it can’t assure this will work as another handler may override this (by being higher up in the list, or being in the machine.config for instance).
Now let’s turn our attention to the modules. As you can see, all modules run on every request. And each module has the power to interfere with what goes in and out. One module that is of primary importance is the authentication module. Check out the MembershipModule of DNN to see this in action. So the authentication module sits there “on the line” and ensures that all components “downstream” know who is issuing the request.
Getting it to work – debugging
As you will now realize: each and every bit here can break the proper functioning of the WebDAV server component. A module may tweak the incoming data. Or it can flag it in IIS as an attack and shut down the response. An error in the handlers section can mean the request never arrives at the WebDAV component. This can be very tricky to debug. But there are two tools at our disposal here: Fiddler and IIS’s Failed Request Tracing. Fiddler should be in your toolbox. It is a terrific tool for debugging web traffic. It makes it so easy, it’s hard to imagine how we ever did without it. I wrote a blog post about using Fiddler to debug WebDAV traffic here. Failed Request Tracing allows us to discover which module threw sand into the machine. And we can see which handler took the call. But of course this only works on failed requests. Google on failed request tracing and you’ll find a multitude of resources.
Recognizing the WebDAV traffic
As said before WebDAV uses very specific verbs. But it also uses GET. All WebDAV traffic to DMX uses the “marker” dmxdav.axd. If that is in the url, then it is a WebDAV request.
Here are some common sources of errors in DMX WebDAV routing:
- Integrated Windows Authentication is on for the site
This means that Windows examines the request to see if you have access to the resource. It doesn’t actually find anything as the url just points to a virtual entity that only DMX understands. Not some file on your server. So Windows Authentication will block the call as it can’t find the resource (404). - The verbs are not allowed
If you find that “GET” to the WebDAV server gets a normal response but PROPFIND etc, don’t, then it’s most likely the verbs are being blocked. - The route is not being wired to DMX
It can happen at various levels. Some bit of software may be examining the route and not like the fact that it is not an aspx and there is no physical resource on disk. Plesk has been known to interfere in this regard. But there are also “anti server attack” solutions that filter out the WebDAV traffic as “suspect”.
Final Notes
I’ve tried to give a deeper expose of what WebDAV is, to help you debug any WebDAV issues. Keep in mind that many bits of software are running on your server and that many components can interfere with the routing. This is why there is no single recipe to get this to work. You may need to wrestle with your server a bit. But once you’ve got it running you’ll have opened up access to DMX in a very user friendly way.