Has it been abandoned totally?<p>It would be really helpful if anybody who has used WebDav can actually share their experience on what worked and what didn't work for them?
The short answer is Yes.<p>WebDAV provides a foundation that many things are built on. As others have noted there is CalDAV and CardDAV that many use all the time.<p>But, it goes beyond that. WebDAV has many of the features we regularly use in object storage. Yet, object storage provides often have their own proprietary API or clone someone elses proprietary API. WebDAV is an open spec.<p>Because WebDAV has been around for so long, there are integration's with just so many things which make it easy to get something going out of the gate. For example, all the major OS support working with it.<p>Not only is it relevant for this but with all the discussions on reviving more of the open web... this is a piece worth looking at.
The Subversion HTTP protocol is WebDaV, so it is most certainly a living standard. Microsoft Office (used to?) support WebDAV URLs in its open dialog, I imagine that's still the case. I'm pretty sure it sees wide use in Microsoft stuff come to think of it. FrontPage used to use it, Sharepoint uses it(?). I suspect some more of their non-Office authoring tools<p>Oh - hell - yes, and Microsoft IIS. That was a big user back in the day, again for FrontPage integration, but you could use it generically too<p>And of course, Windows and OS X still support mounting WebDAV URLs as drives.<p>edit: it ain't going anywhere: <a href="https://www.ics.uci.edu/~ejw/authoring/implementation.html" rel="nofollow">https://www.ics.uci.edu/~ejw/authoring/implementation.html</a>
CalDAV, which is an extension of WebDAV, is widely used for read-write access to a remote calendar. I don't know of any other protocol which is replacing this, although there are bound to be some that technically could. Google, Apple and open source projects like the 'Lightning' Thunderbird extension support CalDAV, at least in part.
Apparently, according to this thread, WebDAV is alive and thriving.<p>CalDAV and CardDAV are certainly alive, but I think they're in a pretty horrible place.<p>I run a Radicale server, which seems very nice, but configuring clients is a nightmare. Every client seems to require different settings, and work to differing degrees.<p>The native Contacts/Calendar apps on OS X were the worst. They connect, work for a few hours or days, and then permanently break. I have to delete and re-add the accounts over and over again until eventually the same settings suddenly work, and they work for some hours or days, and then break again.<p>Thunderbird consistently works, as does Android's DAVdroid, but other clients I've tried have been almost-hit-or-completely-miss.<p>emacs –– <i>EMACS</i> –– has terrible support. This might not sounds like much, what with it being a text editor and all, but this is exactly the sort of place where it usually has 15 different implementations, 2 or 3 of which are really nice. Instead, it's riddled with XML parsing errors, the biggest CalDAV client deletes all of your TODO entries, and there doesn't seem to be a single CardDAV library. I take this as a sign that those protocols are not being widely embraced.<p>That said, when they work they are truly fantastic. I don't particularly care about the underlying protocol, but I pray that CalDAV and CardDAV support gets more consistent and more popular.
Erm, I hope it is. My Nextcloud uses WebDav, CalDav, CardDav and a whole host of other things to sync everything from files to bookmarks and calendar appointments.
I work with Salesforce Commerce Cloud all day. HTTP(S) is the only protocol you can talk to it with, so WebDAV is used constantly to upload code and product images. It's not painful to use, but when PCI requirements made TLS 1.2 mandatory, we had to look around for upload clients that supported WebDAV over TLS 1.2 specifically.
It's still used for a project with another team at my work. For some reason, regular old FTP wasn't good enough for deployment, so this is what they use. They use Microsoft Expression Web 4 to upload/download files, which itself is no longer supported, I believe.
I've used WebDAV successfully for a client's network storage system.<p>I use Apache2 + SQLite for the authentication, here is an example configuration: <a href="https://gist.github.com/aurorabbit/36c509ddeeba2b97c3019534f8dbcce9" rel="nofollow">https://gist.github.com/aurorabbit/36c509ddeeba2b97c3019534f...</a><p>I use buildroot for creating a minimal linux install.
Cryptomator[0] uses WebDAV to locally mount its encrypted vaults natively in the operating system.<p>Also provides vault URLs so you can use third-party clients if need be on a local (and configurable) port.<p>[0] <a href="https://cryptomator.org" rel="nofollow">https://cryptomator.org</a>
I use Apache to run WebDAV at home for my various OmniGroup applications - I like self-hosted cloud/sync services, so I hope OmniGroup continues to support WebDAV for the forseeable future.
When I was shopping around for a Sony Digital Paper tablet I noticed that the original model did in fact support WebDav, I thought that would be ideal, I could have all my notes dump themselves onto the office NAS without any additional proprietary shitware getting involved.
No. And I'm surprised by all the other comments. There are some big systems still using CalDav but the promise of WebDav as read-write version of HTTP got very little adoption and the dev community stopped talking about it years ago.
I still see it as an option in some places, but I don't ever see it used.<p>It had a lot of promise, but very poor actual implementation. I'd still like to see a generalized, cross-platform replacement for SMB/NFS/CIFS.
I tried to use it as replacement for ftp for deployment 14 years ago, in part because I could mount a drive and perform some costly (for a VM at that time) sanity checks on the deployment. It was OK, but too unstable on that kind of connection. Now with jenkins, sonar, docker... CI/CD has become way easier. Also cloud services with a REST API replace pretty much any functionality offered by WebDAV in a simpler, more efficient, more versatile, more interoperable and scalable way, so... Not relevant anymore, I think.
Yandex Disk cloud storage service uses it as a main protocol. They have added some proprietary extensions for their native client, but simple mounting also works.
It is still compiled into nginx by default. That is one of the reasons I have to compile it myself. That would suggest a number of people still use it.
I really like the simplicity of WebDAV especially when combined with Docker. HTTP just works.<p>Have you ever tried to properly set up samba or NFS in a container?
WebDAV is a fantastic file system for the web. It comes built in with auto-resume (content-range header), and in a world where everything but HTTP and HTTPS ports are blocked, I see it as increasingly useful.
I’m using WebDAV for my OmniPresence Sync (syncing OmniGraffle and OmniOutliner, OmniFocus, and DEVONThink.<p>Usually if you have a desktop/mobile application that has a self hosted setup they are using WebDAV.
Look into crdts. Much cleaner, simpler and powerful.<p><a href="https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type" rel="nofollow">https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...</a>
YES,<p>It is done and finished.<p>Webdav was mostly used to provide "easy" access to webdevelopers where at time were using IDEs for Flash (Macromedia) and HTML (Frontpage).<p>Once they finished from the IDE they upload the files.<p>But webdav is a mess to setup (servers and permissions) and was deprecated to better protocols (ssh, scp).
I took this to mean a mispelling of webdev and was giggling at the thought of hackernews being so far ahead of the curve and/or hipster that someone outright asks that question. I was sad to not see responses entertaining the idea.
I don't know anyone using it since Microsoft Frontpage[1] went out of fashion almost 20 years ago.<p>[1] <a href="https://en.wikipedia.org/wiki/Microsoft_FrontPage" rel="nofollow">https://en.wikipedia.org/wiki/Microsoft_FrontPage</a>