WebDAV Isn't Dead Yet
61 points by fanf
61 points by fanf
I completely understand the argument against complicated ACL rules. I have begrudgingly learned the AWS syntax (and it involved a lot of trial and error that I would have hated if I enjoyed tinkering with computers a bit less) as well as various vendors' reimagining of it. It's not great.
But I don't understand how you can make that—very accurate—observation and then insert a snippet of Apache configuration using LDAP. That's even more obscure, difficult to configure, and error-prone! (I'm not just having a knee-jerk reaction to LDAP either, I used to use it on a personal server.)
I don't mean to defend the author (especially because i agree with you), but i wonder if maybe they were more annoyed with "proprietary ACLs"? ...Because the syntax of, say, AWS may not be as easy or cleanly easy to re-use on another hyperscaler, say GCP or MS Azure...whilst the agreed convoluted apache config can easily be copied, used on any other (equivalent version of) Apache on any provider, on any machine that supports apache. I think that portability would have some value there in my opinion.
I don't think this argument holds water either: another provider (assuming it is not your machine) may not run Apache at all, and if it is your own machine, then the OS will influence things like "lock file locations". But let's ignore all of that because LoadModule dav_module libexec/apache24/mod_dav.so is probably the least portable thing anybody could put in any configuration.
In my experience, both httpd configurations and ACL configurations require significant adjustment when moving hosts or doing major OS upgrades, but the ACL configurations benefit somewhat by being purely declarative and written in a slightly cleaner language. They then lose much of that benefit due to the various proprietary extensions and general issues with documentation. They're both bad.
I think i must have lucked out in that the rare times i had to deal with such httpd configs, they migrated pretty easily...so, i defer to your experience...if you've encountered such annoyances, then i can't disagree with you. But, then it means with both ways being bad, it seems to me then that there is a gap of opportunity here...that if webdav were improved, or rather the web servers that support webdav (like apache, etc.) were improved such as to allow for easier configs, then everyone wins! :-)
This article mentions that macOS Finder supports WebDAV. The problem with this argument is that Finder's WebDAV implementation is hot garbage (this QNAP explanation is pretty good but I myself hit this with Nextcloud - it's a generic problem, not server-specific).
Honestly, neither is the Windows implementation (and I'm pretty sure the GVFS implementation isn't great either). There's a good reason why most cloud storage providers have sync clients (or use the OS storage provider infrastructure) rather than use the integrated WebDAV stuff.
It’s not really a Finder feature. The XNU kernel has support. I haven’t looked at the code for ages, but around 2006 I was trying to work out why it didn’t support HTTPS. It turned out that the entire WebDAV subsystem was untouched from OPENSTEP. The code had been written back when WebDAV was new and shiny and then ignored. Given that 2006 was near the tail end of people caring about WebDAV, I’d be shocked if it had received much attention since then.
This is horrifying. Question mark?
I wonder if it's still the case though. My Finder a few years ago supported TLS just fine.
I think they added TLS support around Tiger or Leopard. I doubt the code has been touched since then.
I've been using dufs and recommend.
Nice, this looks more like what I wanted when I used WebDAV. I ran sftpgo for a long time, which despite its name does do WebDAV. ( it also apparently offers s3 too)
I ran
I am curious. Why did you stop?
I stopped needing WebDAV. I was using it to sync org mode files to my phone, but I quit using org mode. :)
And if you don’t need features like creating / deleting / iterating directories or custom metadata, you can just use HTTP — all the basic CRUD stuff can be done with regular requests using If-[None-]Match headers for MVCC.
(OT: Back in 2005 I implemented a prototype forum/chat/wiki app — sort of Slack-like — at Apple using WebDAV as the client/server protocol. (After the release of macOS 10.4 the OS engineering group had a “Small Projects Month” where everyone could work on whatever they wanted for a month. It was awesome.) Unfortunately I was using a PHP WebDAV server library and in the process found all kinds of bugs and missing features I had to fix. That was about when I rage-quit PHP…)
I'm unsure why people act like full-blown S3 is the only way to do it. There are implementations out there such as Garage that implement a subset of the spec that's good enough to work for any application that just wants to put files somewhere (basically every self-hostable application that offers S3 as a storage backend). Because of its simplicity, it's also ridiculously easy to manage.
Curious about the safety/security of using WenDAV to access a password database.
Obviously, the password database is encrypted, at rest and in transit.
I am worried about offline decryption and/or capture now decrypt later attacks though.
WebDAV is just some extensions on HTTP. So its security (at least, the bits relevant to your question) basically just boils down to TLS. There isn't anything particularly special here about accessing a password database.
The method used to transfer the bytes is irrelevant, if a threat actor is preforming CNDL against you, they'll just capture the raw stream of bits.
When i first learned that software like MS sharepoint and NextCloud used webdav under the hood, i was surprized! But, also wondered if such big names used webdav, why doesn't it perform better? I ask this not really knowing the under-the-hood details enough of webdav. I mean, i know enough basic understanding of http, but merely not enough around webdav...so maybe if i knew more of it, maybe i'd understand why it feels like webdav is slower than it should be. Then again, maybe its simply that the popular implementations of webdav in popular software was made years, sufficed enough for folsk, and then they never returned to optimize things, hmmm, i wonder?
I use Caddy and statically compile in the webdav module. My config (a single user is easier, of course):
{
order webdav before file_server
}
my.cool.domain {
basicauth {
myuser $bcRyteDP4ssW0rd
}
webdav /dav/* {
root /var/lib/caddy/dav
prefix /dav
}
}
Actually, come to think of it, I don't use webdav for "files", but for Super Productivity sync, since WebDAV is the main OSS sync option.