WebDAV is a very powerful feature of DMX that allows you to access the documents ‘directly’ from Windows or any other client that supports the protocol. The protocol uses HTTP and extends this to allow for the various operations to take place. This means it will work across firewalls, i.e. it will work if you can browse a web page. But it does require a number of tweaks to both the server and the client to get it to work. And this is where the fun starts. If you thought browser compatibility was a nightmare, welcome to WebDAV compatibility. As always, there is a protocol defined in a RFC by the IETF, and then there are the manufacturers of software that each do their own thing. And as always, Microsoft is the dominant party that does not always play by the rules. This article will help you identify where things are going wrong hopefully.
Introduction: 101 on WebDAV
WebDAV, as said before, operates on top of the http protocol. This is the same protocol that’s used by browsers to get web pages and send data to web sites. All this traffic is in plain text (well, unless you’re encrypting, but let’s keep things simple for now). Typically, a browser will issue a command to fetch a web page. That command might look like this:
GET /index.htm HTTP/1.1
Host: www.bring2mind.net
GET is the so-called verb of this request. /index.htm is the resource. HTTP/1.1 is the protocol specification and host, well, you get the picture. The Internet knows what to do with this command. It’s routed to the host, and the host replies with the requested page. Each request and response consist of 2 parts: a set of headers and the contents. The headers provide information about the content as you can expect. For example: a web browser will send a header User-Agent with an identifier of the browser (what brand, version, etc). And the server will include similar header called ‘Server’.
WebDAV
WebDAV extends the http protocol by adding some additional verbs to deal with locking and saving documents for instance. These are the verbs listed in the installation manual under the WebDAV segment. The resource that follows the verb must be a path just like you’d have a Windows path to a file. So
PROPFIND /Basefolder/Project%20Folders/Project%20X/My%20Document.doc HTTP/1.1
will request the properties of a document called ‘My Document.doc’ under ‘BaseFolder/Project Folders/Project X’ (note the %20 is internet code for ‘space’). Most WebDAV servers like DMX will translate that path to a virtual resource in their own system. Remember that DMX does not actually store the documents on disk in the same folder structure as you see it when you browse it. The server must handle the mappings.
Most responses through WebDAV are in XML. Something like the following for instance:
infinityopaquelocktoken:ccf4b32b-ebd4-44c8-b91c-5605877150f3Second-0Peter Donker
Other traffic is usually the transfer of the files themselves (in conjunction with the GET and PUT verbs).
Analyzing web traffic using Fiddler
If you really want to know what’s going on between a (web) server and client (i.e. browser), you’d love to sit on the wire and read the traffic that they send between each other. There are many network sniffing tools that will allow you to do so, but by far one of the simplest to use is Fiddler (http://www.fiddler2.com). When it’s running it creates a proxy on your own machine (i.e. a bit of software through which all internet traffic passes) and captures the traffic between your browser and the server. It can present this traffic in various ways depending on your needs (I mostly want to view the traffic in its raw state, but you can view just the headers for instance). In the remainder of this article I’ll assume you have downloaded and installed Fiddler and that we’re using IE (as it allows us to bridge from browser to opening Word). Start up IE and select to start Fiddler:
Now you’ll see the main Fiddler UI:
On the left you’ll see so-called sessions listed. Sessions are requests and their responses. If you click on one, you’ll see the details of that session appear on the right hand side. When we first request a DMX page you’ll see something similar to this traffic:
The blue session is the actual web page (Default.aspx and querystring parameters), the pink sessions are css, the grey images, and the green Javascript files. Obviously you can tune all this to your own desire. Note the Body column. You’ll know when stuff is being retrieved from local browser cache if you see sessions where the resource is a JS file for instance and the body is 0.
Looking at DMX WebDAV traffic
Now let’s click on ‘Open in Windows Explorer’ on a folder of ours:
The folder opens in Windows (I’m using Vista in Classic XP look here):
We can drop in files or double click Office files to edit them, etc. In Fiddler you’ll see WebDAV traffic build up. The reason is that Fiddler not only captures the traffic between your IE and the server, but also Windows Web Folders (which is the official name for the component handling WebDAV in Windows) and the server. Here is an example of the sessions:
As you can see the calls to Default.aspx give way to calls beginning with dmxdav.axd. This is where the WebDAV traffic happens. The dmxdav.axd resource is an identifier which IIS will route to the DMX WebDAV component if the server is correctly configured (see installation manual). Underneath the identifier the document tree starts for a given portal. So you can see this as the folder called ‘Document Exchange’ in DMX which is the absolute root.
Now let’s examine one of the sessions. If I click on the /dmxdav.axd request this is what I may see on the right in Fiddler (note I’ve switched to raw view for both request and response):
The highlighted elements should give you an indication if something is wrong. Let’s go through them.
The browser’s request
If it is not a WebDAV call, then we shouldn’t use it to analyze any WebDAV issues. Typical WebDAV verbs are: PUT, PROPFIND, HEAD, LOCK, UNLOCK, MOVE. There are more, but we’ll focus on just a few for our analysis here. PROPFIND is the most common one. The client is looking at the server and mapping out what is there. The response is a (sometimes lengthy) XML fragment. HEAD is most often used as a test to see if something is there. The server will normally reply with either OK or NOT FOUND. LOCK, UNLOCK and MOVE are self explanatory.
If you’re debugging issues of opening an editing a document, check out the locking traffic. Does Word send a LOCK request? If so, what was the response? If Word can’t get a lock, then you’ll see your document opened ‘Read Only’.
DMX WebDAV cookie
DNN by default uses Windows forms authentication and a cookie to store the user’s login status. Because this cookie is not always emitted by the browser in calls, DMX WebDAV had to create it’s own cookie. If the cookie is present, then it is used to authenticate the user. This mechanism allows you to ‘Open in Word’ directly from IE. If the cookie is not emitted by the client (browser or otherwise) then you may expect the response to include Authenticate headers. This is a sign that the server is challenging the client to authenticate itself. Depending on the type of authenticate header you’ll get an indication if something is wrong with the server setup. This would be a valid challenge:
You’ll notice the Digest authentication header. It asks the client to identify itself using Digest authentication. If you don’t see this and only Negotiate/NTLM authentication headers, chances are that IIS is not routing the call to DMX but treating it a a regular call to a Windows resource and asking the client for a Windows login. This will fail of course. Check whether the web server is not running a WebDAV server of its own (as it overrides what IIS does on the DNN site). It could also be a sign of another authentication mechanism overriding the installation.
Agent
The agent identifies who is placing the call. This can come in handy when we need to determine if you have the latest patches installed on your Windows machine.
DMX WebDAV version
Since version 05.00.04 DMX is emitting this identifier in the response. If it’s not there in the response, it’s not DMX WebDAV you’re talking to. This is a very useful piece of information when debugging.
Response
The responses are normally human readable/understandable. Like 200 OK. Or 404 Not found. Use this to identify which calls are not getting the desired response.
Finally
You might very well see a lot of ‘Not found’ traffic:
This is not necessarily an error. Windows will look for files with particular names (like _avt) to check for things it could do that go beyond simple check out, put, check in, etc.
Conclusion
I hope this article will give you enough information to do a first debugging of WebDAV issues. Secondly it should help communicating with us. You can select a number of sessions in Fiddler and select ‘Save in ArchiveZip…’ which will make a compact file that can be opened using Fiddler to examine the traffic.
