WebDAV Selfhosting

2021-02-06

WebDAV is a protocol that gets no respect. It’s a dumb name, and a strange extension of REST, using nonstandard methods and all-XML response bodies. Many people hate it, associating it with other protocols built on top of it, specifically CardDAV and CalDAV (of which there are many passionate opinions).

In reality, it’s a great all-purpose two-way file transfer protocol. If you want a remote filesystem, there isn’t a better choice.

Why use it

The biggest advantage is that webdav is just HTTPS, meaning:

Clients/servers are pretty easy to write in any language, you don’t need a webdav-specific library to do it
Regular HTTP clients can still download from it normally
You get TLS and all the certificate and cipher selection that comes with it
- note: You’ll encounter SFTP/SSH people who will debate the last point (the discussion about the two is interesting in itself), but we don’t have to get into it.

The more important advantage is the widespread support. It has to be re-emphasized that clients exist for every platform, if native support is not provided. Cx for android, windows, Most flavors of linux via davs://, etc.

Foundations

The easiest way to think about WebDAV is that it’s an overlay filesystem that you can interact with (and mount) over REST. It makes all the usual filesystem operations (writes, list, properties) available over HTTP. If you’ve ever uploaded a file on a website or gotten a directory listing, webdav is a standard for doing that (that none of those sites use).

There are a few different method names (PROPFIND, COPY, LOCK, MKCOL, MOVE, etc) representing the usual filesystem operations that aren’t clearly present in the usual REST methods. This throws people off, since everyone mostly sticks to writing POST/PUT (and sometimes PATCH if you’re cool), but this isn’t un-restful. Using new methods is perfectly acceptable, especially in cases like this.

Servers for it vary in quality. Generally, it’s something that ships with a larger product, rather than being a standalone product itself. For full disclosure, part of my incentive for writing this was because I wrote a standalone webdav server, and use it extensively.

Is it bad?

There are two common themes around webdav criticism, that it’s insecure and that it’s inefficient. Neither is true.

One of the harshest criticisms of webdav comes from noting how many vulnerabilities exist for its servers. This isn’t a condemnation of the protocol itself, it’s a condemnation of specific (mostly Microsoft) servers. These sorts of things are hard to level against a protocol, it’d be a bit like saying HTTP is a huge vulnerability because so many exploits operate over HTTP. It isn’t like DNS, which is insecure as a fluke of design history.

There is an argument to be made about inefficiency. Specialized protocols are usually designed for efficient file transfers, and there is always a better way. But these criticisms usually confuse webdav with caldav/carddav - which are standards built on top of webdav. It is, again, like criticizing HTTP because your Mega.nz downloads take a long time.

The efficiency of webdav is the same as any HTTP protocol. If you’re comfortable with the efficiency uploading and downloading files over HTTP, you must therefore not be uncomfortable with the efficiency of doing so over webdav - it’s the same thing.

To the point, almost all criticism of webdav isn’t about webdav, it’s about some specific bad experience someone had with something related to it.