alt Hacker NewsMany hells of WebDAV
Comments
I once implemented a WebDAV server in PHP. The standard isn't that bad and clients are more or less following the standard. It's still horrible how they are doing that. I saw behaviors when opening a single file like:
- does / exists?
- does /path/to exists?
- does /path/to/file exists?
- create a new file /path/to/file.lock
- does /path/to/file.lock exist?
- does / exist?
- does /path/to/file exists?
- lock /path/to/file
- get content of /path/to/file
- unlock /path/to/file
- does /path/to/file.lock exist?
- remove /path/to/file.lock
Also the overwrite option was never used. You'd expect a client to copy a file, get and error if the target exists, ask user if it's ok, send same copy with overwrite flag set to true. In reality clients are doing all steps manually and delete the target before copying.
It was satisfying seeing it work at the end, but you really need to test all the clients in addition to just implementing the standard.
Mounting WebDAV -- if you are in a situation, where you have to do it (e.g. own^W^W^Wnextcloud) is such an adventure. Everything - mac, win, linux - supports WebDAV. You mount and it works! Then you notice HOW it works: files are downloaded in full before program can access them, some operations are super slow, some fail or time out, plaintext credentials in mysterious places...
I heard DeltaV is very advanced, and Subversion supported it. I'm afraid to ask.
I built a go caldav server and client for my task management app (http://calmtasks.com) and had a similar experience, which surprised me. Go generally has at least one good, working, and well documented implementation for all standard protocols.
Apple calendar supports caldav but in a way not specified in the spec. I basically had to send requests and responses to figure out how it works. I would be willing to open source my server and client (alot of which was built using/on top of existing libraries) if there is interest.
Articles like this shitting on WebDAV really rubs me the wrong way as I've seen first hand discussion that goes like: "internet say WebDAV is hell, what's the better alternative? S3 or course!" And now every cloud provider instead of providing a webdav interface provide an S3 one and it's worse by every possible way, you can't rename a file / folder because S3 does not support that, you can't support a classic username / password authentication mode but are force to use an uggly access_key_id and secret_access_key, can't bash your way around with a simple curl command to do anything because generating the signature requires a proper programming language and you have to trust Amazon to do the right thing instead of going through the RFC process except they've already shown a few months ago their complete lack of care for any s3 compliant server by introducing a breaking change that literally broke the entire ecosystem of "S3 compliant" implementations overnight and without any prior warning.
I hope WebDAV had a better reputation, it carries the original promise of s3 of being actually simple but S3 won the war with evangelism. I would much have preferred a world where new version of the webdav protocol are made to address the quirks exactly like what happened with protocols like http, oauth, ...
When working on pimsync[1] and the underlying WebDAV/CalDAV/CardDAV implementation in libdav, I wrote "live tests" early on. These are integration tests, which use real servers (radicale, xandikos, nextcloud, cyrus, etc). They do things like "create an event, update the event, fetch it, validate it was updated". Some test handle exotic encoding edge cases, or trying to modify something this a bogus "If-Match" header. All these tests were extremely useful to validate the actual behaviour, in great deal because the RFCs are pretty complex and easy to misinterpret. For anyone working on the field, I strong suggest having extensive and easy to execute integration tests with multiple servers (or clients).
All servers have quirks, so each test is marked as "fails on xandikos" or "fails on nextcloud". There's a single test which fails on all the test servers (related to encoding). Trying to figure out why this test failed drove me absolute crazy, until I finally understood that all implementations were broken in the same subtle way. Even excluding that particular test, all server fail at least one other test. So each server is broken in some subtle way. Typically edge-cases, of course.
By far, however, the worst offender is Apple's implementation. It seems that their CalDAV server has a sort of "eventual consistency" model: you can create a calendar, and then query the list of calendars… and the response indicates that the calendar doesn't exist! It usually takes a few seconds for calendars to show up, but this makes automated testing an absolute nightmare.
> Ah, looks like it was somewhat superseded by RFC 4918, but we’re not going to tell you which parts! How about those extension RFCs? There’s only 7 of them…
This is a major complaint I have with RFCs.
If you want to know the current standard for a protocol or format you often have to look at multiple RFCs. Some of them partially replace parts of a previous RFC, but it isn't entirely clear which parts. And the old RFCs don't link to the new ones.
There are no less than 11 RFCs for HTTP (including versions 2 and 3)
I really wish IETF published living standards that combined all relevant RFCs together in a single source of truth.
Postel's Law strikes again. What's the point of having RFCs with MUST and SHOULD if everyone does what they need? You end up with French cafe[0] implementations.
I once implemented JavaScript's new async-for in plain Objective-C for a WebDAV app that I wrote for a client, about 15 years ago. I was so much smarter back then than I am now. Does this happen to everyone? You just go downhill? Anyway I'm sure there were complex edge cases of WebDAV that I missed, but it worked really well in all my tests, and my client never complained about it.
Actually done some WebDAV, did a small client (talking to Apache) from JS that worked well enough for my purposes.
The nasty surprise was doing the server-side (for a hobby-project), many layers. Luckily found out that something called DavTest exists (it's included with Debian) so testing most basic things wasn't too bad.
Then tried mounting from Windows and running into a bunch of small issues (iirc you need to support locking), got it to mount before noticing notes about a 50mb file-size limit by default (raisable.. but yeah).
It's a shame it's all such a fragmented hodge-podge because adding SMB (the only other "universal" protocol) to an application server is just way too much complexity.
I’m pretty sure there is a complete webdav implementation which ships with golang in the stdlib… Why do you need an external library for this? You just need to wrap it in a main.go and boom, webdav server.
On not implementing half the RFCs, this is almost always true... some parts of "standards" are impractical or very difficult to implement, have no practical use or just aren't needed for your use case.
I created a test LMS in 2003 based on SCORM, at the time there really wasn't a good server for the standard... The main point was to be able to test the content which the company was hired to generate. I didn't implement several points of functionality that I just didn't need, didn't care about, and would have been difficult to implement.
That testing LMS turned into an actual product used by several aerospace companies (a few F100's, etc) and was in production for over 15 years. I remain friends with the company owner... It was about 12 years later than someone had an actual course that used one of the features that wasn't implemented... and even then, they only implemented it the half way needed, because it would have been difficult to do the rest.
> reverse engineering existing clients and servers by inspecting their requests and responses.
What a strange process... why not read the source code of an open source working library (easy to test, run a client made by someone else on its server, and vice versa) in a language close to the target?
Why not use then those tests as a way to verify your own work after?
FWIW I'm using WebDAV, both with clients and with my own self hosted servers, on a daily basis and... it works.
I have a fun experiment for OP, since you already walked the reverse engineering route.
Why not download the most popular DAV libraries from various languages, Java, C++, PHP, etc. Regardless how ancient they are.
And then have AI like Claude to analyze and bring in the improvements to your own Go library?
I was doing something like that for Kerberos and Iceberg Rest Catalog API, until I got distracted and moved on to other things.
Golang is one of the only languages with a more or less working library. I built with it and using some hacks got it hooked up to AWS API Gateway with Lambda. Reading the room, the lack of language support does make it pretty suspect in 2026, even if the client support is still pretty good. Recently I have abandoned in favor of AWS Mountpoint (rust S3 mounting) and combined with Lambda object get and list functions have achieved most of the same functionality. The downside being that you lose the ability to talk to the many varied clients like an old HP printer which (obviously) can't use FUSE.
I started running a DAV server for calendar and contacts. Smooth failing.
> This library was lacking some key features we needed, like server-side collection synchronization
Yes! This is my #1 issue with the library as well.
16 years ago, I wrote a Java client that is still in use today in quite a number of products. It wasn't that bad.
WebDAV/CalDAv and CardDAV are a minefield for users and devs. I would love to see something new.
I honestly didn't know WevDAV was still a thing. It seems like a nightmare from which we should have woken up long ago. I do sympathize though. Every service implements (or implemented) it differently, or spottily, or partially. Is it another example of the adage that "even your bugs have users"?
I've been playing with a toy app that dabbles in the Cal/CardDAV space, and it blows my mind that for all the power latest generation languages have, the thing I keep coming back to is PHP-based Sabre/DAV. That's not to say PHP isn't modern now, but instead a reflection of my surprise that there doesn't appear to be any other library out there that does as good or nearly as good a job at DAV as that one, and that one is pretty darn old.
On a different point, I don't think the author's point about having to "also" inspect the headers is a fair critique of DAV - HTTP headers are to indicate a certain portion of the request/response, and the body a different one. I wish it was simpler, but I think it's an acceptable round peg in a round hole use of the tools.