For the past few weeks, I've been learning about WebDAV and how it might function in my mobile photo upload app for Firefox OS. WebDAV, or Web Distributed Authoring and Versioning, is a protocol that sits on top of HTTP, and extends HTTP 1.1 (the version of HTTP still in common use) by adding additional methods and headers. WebDAV's extra methods are designed to aid the creation and modification of documents on a server where multiple parties could be accessing resources at any given time.

When I first started reading about WebDAV, I was pretty discouraged. There aren't many resources for learning about WebDAV beyond the standard specification (RFC) itself, which is about 37,000 words long. A good portion of the standard is XML examples, appendices, and errata, but it's still a similar length to C.S. Lewis' The Lion, the Witch and the Wardrobe, and does not have the benefit of illustrations of talking animals.

An overview of WebDAV

Although the specification is long, it's not terribly complicated. Keeping in mind Dave's maxim about the internet just being a bunch of text, I was able to digest the RFC once I started thinking of it as HTTP with an extra layer expressed through XML.

The skeleton of a request

When I started reading about WebDAV, I was a little flummoxed by how often the standard specification was discussed without ever actually talking about what a request looks like. A WebDAV request is essentially an HTTP request fortified with XML. Here's what an example might look like if I sent a PROPFIND request to an image stored on an ownCloud server.

    PROPFIND /remote.php/webdav/foo.jpg HTTP/1.1
    Host: someowncloudinstallation.org
    Accept-Encoding: identity
    Content-Length: 84
    Depth: 0
    Content-Type: application/xml
    <?xml version='1.0' encoding='UTF-8'?>
    <D:propfind xmlns:D='DAV:'>
        <D:propname/>
    </D:propfind>

PROPFIND is a method, just like GET or POST. WebDAV builds on the pool of established HTTP methods (GET, POST, DELETE...) and adds specific methods that are relevant to authoring situations where multiple parties could be accessing or editing files. PROPFIND (property find) is a method that retrieves a resource's WebDAV properties. These properties generally include things like author and modification date.

The remaining headers probably look familiar if you're acquainted with HTTP. In the XML snippet that constitutes the request body, I've used <D:propname/> to specify that I want list of property names without the property values (i.e., the property keys without their values).

The response to this request will return a list of the image's properties as XML:

    HTTP/1.1 207 Multi-Status
    Content-Length: 724
    Content-Type: application/xml; charset=utf-8
    Date: Mon, 09 Jun 2014 18:28:22 GMT
    <?xml version="1.0" encoding="UTF-8"?>
    <d:multistatus xmlns:d="DAV:">
        <d:response>
            <d:href>http://someowncloudinstallation.org/remote.php/webdav/foo.jpg</d:href>
            <d:propstat>
                <d:status>HTTP/1.1 200 OK</d:status>
                <d:prop>
                    <d:auto-version />
                    <d:checked-in />
                    <d:comment />
                    <d:creationdate />

                    (...trimmed for length...)

                    <LastAccessUtc xmlns="MyNs" />
                </d:prop>
            </d:propstat>
        </d:response>
    </d:multistatus>

So, we now know that we could potentially retrieve any of these properties (such as creationdate, or LastAccessUtc) using PROPFIND.

Properties

Properties can be "live" or "dead." Live properties are things that the server computes, observes, or calculates, such as getcontentlength. Dead properties, on the other hand, are set and maintained by WebDAV users and user processes. In the above example, the comment property is almost certainly a dead property that is manually updated by users.

WebDAV methods

PROPFIND is one of seven new methods defined by the WebDAV standard.

  • PROPFIND retrieves a resource's properties.
  • PROPPATCH changes and/or deletes properties on a resource.
  • MKCOL creates collections.
  • COPY copies a resource from one location to another.
  • LOCK puts a lock on a resource. This could be a shared (soft) lock that says, "be careful, another person or process is editing this," or it could be an exclusive lock that bars any other agents from editing the file while the lock is active.
  • UNLOCK removes a lock.

Additionally, GET, PUT, DELETE, and other methods supported by the extended HTTP 1.1 protocol work more or less as one would expect on WebDAV-enabled servers, although special cases might occur when they are used with collections of resources (such as a directory on a web server).

Collections

WebDAV terminology often references "collections." Generally, it's safe to imagine a collection as a directory. In most WebDAV implementations, the collections that users are dealing with are directories on a server. However, some WebDAV methods return significantly different responses when called on collections: for example, the standard specifies that a GET request to collection somefoobarbazbat.org/images should return something, but doesn't specify what that something is. The server could return something plausible, like a list of files in that directory. Or, it could return something completely unrelated to the collection's content... and still be within specification guidelines!

Locks

WebDAV resources can be locked and released using the LOCK and UNLOCK methods. There are two types of locks: shared locks and exclusive locks. A shared lock functions like a flag. If one user places a shared lock on a file, other users accessing that file will be warned that the file may be undergoing changes, but their editing privileges will not be revoked. An exclusive lock, on the other hand, temporarily bars other parties from editing the file.

WebDAV today

Considering how well defined the standard specification is, I'm a little surprised that WebDAV is used in so few contexts today. None of the public WebDAV servers set up years ago were still running, and I ended up having to rely on existing ownCloud servers and my own instances for testing.

While WebDAV seems somewhat uncommon in contrast to other protocols (like FTP), CalDAV, an extension of WebDAV made specifically for calendar management, appears to still be in frequent use, as it is utilized by Apple Calendar and multiple Mozilla projects.