This blog post didn't convince me. I must assume the default for most web devs in 2025 is hosting on a Linux VM and/or mounting the static files into a Docker container. SFTP is already there and Apache is too.
The last time I had to deal with WebDAV was for a crusty old CMS nobody liked using many years ago. The support on dev machines running Windows and Mac was a bit sketchy and would randomly have files skipped during bulk uploads. Linux support was a little better with davfs2, but then VSCode would sometimes refuse to recognize the mount without restarting.
None of that workflow made sense. It was hard to know what version of a file was uploaded and doing any manual file management just seemed silly. The project later moved to GitLab. A CI job now simply SFTPs files upon merge into the main branch. This is a much more familiar workflow to most web devs today and there's no weird jank.
Author seems to conflate S3 API with S3 itself. Most vendors are now including S3 API compatibility into their product because people are so used to using that as a model
"FTP is dead" - shared web hosting would like a word. Quite a few web hosts still talk about using FTP to upload websites to the hosting server. Yes, these days you can upload SSH keys and possibly use SFTP, but the docs still talk about tools like FileZilla and basic FTP.
Also worth noting that FTPS (FTP over TLS) exists and obviates the fuss around SSH TOFU and key management etc. Especially given we're in the era of free certificates via Let's Encrypt, this is a great option.
The main downside is people will sometimes assume you mean SFTP (not having heard of FTPS or realising they are different), and then get upset when it doesn't work as they expect. However good tooling will support both e.g. Filezilla.
Relatedly, is there a good way to expose a directory of files via the S3 API? I could only find alpha quality things like rclone serve s3 and things like garage which have their own on disk format rather than regular files.
I was surprised, then not really surprised, when I found out this week that Tailscale's native file sharing feature, Taildrive, is implemented as a WebDAV server in the network.
I built a simple WebDAV server with Sabre to sync Devonthink databases. WebDAV was the only option that synced between users of multiple iCloud accounts, worked anywhere in the world and didn’t require a Dropbox subscription. It’s a faster sync than CloudKit. I don’t have other WebDAV use cases but I expect this one to run without much maintenance or cost for years. Useful protocol.
One interesting use of WebDAV is SysInternals (which is a collection of tools for Windows), it's accessible from Windows Explorer via WebDAV by going to \\live.sysinternals.com\Tools
I wonder how much better WebDAV must have gotten with newer versions of the HTTP stack. I only used it briefly in HTTP mode but found the clients to all be rather slow, barely using tricks like pipelining to make requests go a little faster.
It's a shame the protocol never found much use in commercial services. There would be little need for official clients running in compatibity layers like you see with tools like Gqdrive and OneDrive on Linux. Frankly, except for the lack of standardised random writes, the protocol is still one of the better solutions in this space.
I have no idea how S3 managed to win as the "standard" API for so many file storage solutions. WebDAV has always been right there.
On the same topic, and because I believe too that WebDAV is not dead, far from it, I published a WIP lastly, part of a broader project, that is an nginx module that does WebDAV file server and is compatible with NextCloud sync clients, desktop & Android. It can be used with Gnome Online Accounts too, as well as with Nautilus (and probably others), as a WebDAV server.
I'm using WebDAV to sync files from my phone to my NAS. There weren't any good alternatives, really. SMB is a non-starter on the public Internet (SMB-over-QUIC might change that eventually), SFTP is even crustier, rsync requires SSH to work.
Recently set up WebDAV for my Paperless-NGX instance so my scanner can directly upload scans to Paperless. I wish Caddy would support WebDAV out of the box, had to use this extension: https://github.com/mholt/caddy-webdav
> In fact, you're already using WebDAV and you just don't realize it.
Tailscale's drive share feature is implemented as a WebDAV share (connect to http://100.100.100.100:8080). You can also connect to Fastmail's file storage over WebDAV.
I wrote both the WebDAV client (backend) for rclone and the WebDAV server. This means you can sync to and from WebDAV servers or mount them just fine. You can also expose your filesystem as a WebDAV server (or your S3 bucket or Google Drive etc).
The RFCs for WebDAV are better than those for FTP but there is still an awful lot of not fully specified stuff which servers and clients choose to do differently which leads to lots of workarounds.
The protocol doesn't let you set modification times by default which is important for a sync tool, but popular implementations like owncloud and nextcloud do. Likewise with hashes.
However the protocol is very fast, much faster than SFTP with it's homebrew packetisation as it's based on well optimised web tech, HTTP, TLS etc.
In your opinion, is WebDAV good enough to be the protocol for exposing file systems over HTTP, or is there room for something better? I was bullish on Solid but they don't seem to be making much progress.
That's some wishful thinking. I understand the case for JMAP above IMAP, I understand how "it makes sense" to NIH the rest of cal/cardDAV, I'm not sure what the sales pitch for file transfer is, though, especially when the ecosystem is pretty much inexistant.
> While writing this article I came across an interesting project under development, Altmount. This would allow you to "mount" published content on Usenet and access it directly without downloading it... super interesting considering I can get multi-gigabit access to Usenet pretty easily.
And yet, I can never seem to find a decent java lib for webdav/caldav/carddav. Every time I look for one, I end up wanting to write my own instead. Then it just seems like the juice isn't worth the squeeze.
45 comments
[ 2.6 ms ] story [ 55.9 ms ] threadThe last time I had to deal with WebDAV was for a crusty old CMS nobody liked using many years ago. The support on dev machines running Windows and Mac was a bit sketchy and would randomly have files skipped during bulk uploads. Linux support was a little better with davfs2, but then VSCode would sometimes refuse to recognize the mount without restarting.
None of that workflow made sense. It was hard to know what version of a file was uploaded and doing any manual file management just seemed silly. The project later moved to GitLab. A CI job now simply SFTPs files upon merge into the main branch. This is a much more familiar workflow to most web devs today and there's no weird jank.
Sftpgo also supports webdav, but for use cases in the article sftp is just better.
Exhibit A: https://help.ovhcloud.com/csm/en-ie-web-hosting-ftp-storage-...
The main downside is people will sometimes assume you mean SFTP (not having heard of FTPS or realising they are different), and then get upset when it doesn't work as they expect. However good tooling will support both e.g. Filezilla.
https://tailscale.com/kb/1369/taildrive
The go stdlib has quite a good one that just works with only a small bit of wrapping in a main() etc.
Although ive since written one in elixir that seems to handle my traffic better..
(you can also mount them on macos and browse with finder / shell etc which is pretty nice)
It's a shame the protocol never found much use in commercial services. There would be little need for official clients running in compatibity layers like you see with tools like Gqdrive and OneDrive on Linux. Frankly, except for the lack of standardised random writes, the protocol is still one of the better solutions in this space.
I have no idea how S3 managed to win as the "standard" API for so many file storage solutions. WebDAV has always been right there.
Have a look there: https://codeberg.org/lunae/dav-next
/!\ it's a WIP, thus not packaged anywhere yet, no binary release, etc… but all feedback welcome
What else?
We need to keep using open protocols such as WebDAV instead of depending on proprietary APIs like the S3 API.
Tailscale's drive share feature is implemented as a WebDAV share (connect to http://100.100.100.100:8080). You can also connect to Fastmail's file storage over WebDAV.
WebDAV is neat.
The RFCs for WebDAV are better than those for FTP but there is still an awful lot of not fully specified stuff which servers and clients choose to do differently which leads to lots of workarounds.
The protocol doesn't let you set modification times by default which is important for a sync tool, but popular implementations like owncloud and nextcloud do. Likewise with hashes.
However the protocol is very fast, much faster than SFTP with it's homebrew packetisation as it's based on well optimised web tech, HTTP, TLS etc.
In your opinion, is WebDAV good enough to be the protocol for exposing file systems over HTTP, or is there room for something better? I was bullish on Solid but they don't seem to be making much progress.
Hahahaha, haha, ha, no. And probably (still)more used than WebDAV
pls send help
There is also NzbDav for this too, https://github.com/nzbdav-dev/nzbdav
And yet, I can never seem to find a decent java lib for webdav/caldav/carddav. Every time I look for one, I end up wanting to write my own instead. Then it just seems like the juice isn't worth the squeeze.
https://github.com/lookfirst/sardine
Still going.