TL;DR
A small team building a WebDAV/CalDAV client and server for Homechart found the published specs hard to follow and real-world implementations inconsistent. They abandoned attempting a full RFC implementation, instead reverse-engineering traffic from major clients and servers and building custom XML tooling in Go to get an MVP working.
What happened
The team set out to build a WebDAV/CalDAV client and server for Homechart and evaluated existing Go code, including go-webdav, but found it missing features they needed—most notably server-side collection synchronization—and incompatible with their data model. They spent roughly a month trying to implement the RFCs (including older RFC 2518 and its successor RFC 4918 plus extensions) before abandoning a full-spec approach as too encumbered by legacy cruft. Instead they captured HTTP traffic from target clients (Apple Calendar, DavX, Thunderbird) and servers (Apple iCloud, Google Calendar, Radicale) using HTTP proxies and packet inspection to map the practical API surface. They also created an XML wrapper for Go to handle the unstructured XML patterns WebDAV uses, enabling marshal/unmarshal without rigid structs. Testing revealed significant drift from RFCs: some major providers advertise capabilities they don’t fully implement, and clients vary widely in supported synchronization methods. The authors conclude the work is costly and warn others about the effort required.
Why it matters
- Published standards may diverge from major vendor implementations, complicating interoperability for smaller projects.
- Developers may need to reverse-engineer live traffic rather than rely solely on RFC text to achieve compatibility.
- Tooling gaps (for example, XML handling in Go) can add development overhead and require bespoke solutions.
- Nonstandard behavior from large providers can force smaller implementers to build fragile workarounds rather than use clean, spec-driven designs.
Key facts
- Project: building a WebDAV/CalDAV client and server for Homechart (source project named Homechart).
- Existing Go library go-webdav was evaluated but lacked server-side collection synchronization and aligned poorly with the team’s data model.
- The team spent nearly a month attempting to implement RFCs (including RFC 2518 and RFC 4918 and extensions) before stopping due to legacy complexity.
- They reverse-engineered real traffic from clients (Apple Calendar, DavX, Thunderbird) and servers (Apple iCloud, Google Calendar, Radicale) using HTTP proxies and packet capture.
- Both request/response bodies and headers were important to inspect because WebDAV implementations vary in both.
- They built a custom XML wrapper around Go’s XML library to manage XML nodes more flexibly and avoid writing many rigid structs.
- When validating their MVP, they observed that Apple and Google do not implement large portions of the RFCs and sometimes advertise generic capabilities.
- CalDAV clients differ in synchronization approaches: many favor sync-collection, while Apple Calendar uses ctags and etags instead.
What to watch next
- Compatibility differences between major providers (Apple, Google) and smaller servers—expect advertised capabilities to be unreliable.
- How CalDAV clients you need to support request synchronization (sync-collection vs. ctags/etags) and adapt accordingly.
- The need for custom XML tooling in Go if you handle WebDAV’s flexible XML responses.
Quick glossary
- WebDAV: An extension of HTTP that adds methods and headers to support remote authoring and collaborative editing of web resources.
- CalDAV: A calendaring extension to WebDAV that defines how calendar data is stored and synchronized over HTTP.
- RFC (Request for Comments): A formal document from the Internet Engineering Task Force (IETF) that describes protocols, standards, and practices for the internet.
- sync-collection: A CalDAV synchronization method designed to efficiently synchronize collections of calendar resources between client and server.
- ETag/CTag: Values provided by servers to help clients detect changes to resources; ETag is per-resource, while CTag is often used to signal collection changes.
Reader FAQ
Is the existing go-webdav library sufficient?
For the team’s needs it was not; go-webdav lacked server-side collection synchronization and had incompatible interfaces.
Did the authors rely solely on RFCs to implement WebDAV/CalDAV?
No. After about a month trying to follow the RFCs, they switched to reverse-engineering traffic from real clients and servers.
How did they test compatibility with other implementations?
They captured and inspected HTTP requests and responses from target clients and servers using HTTP proxies and packet capture tools.
Are major providers fully RFC-compliant?
The authors observed that Apple and Google do not implement significant portions of the RFCs and sometimes advertise capabilities they do not fully support.
Blog Many Hells of WebDAV Many Hells of WebDAV Standards are great, until they aren’t By Candid Development | 2026-01-07 Implementing a WebDAV/CalDAV client and server should be easy! It’s…
Sources
- Many hells of WebDAV
- RFC 7809 – Calendaring Extensions to WebDAV (CalDAV)
- spaceraccoon/Challendar-TISC-2022-Challenge-7
- Setting up WebDAV, CalDAV, and CardDAV servers
Related posts
- Government site posts ‘Eat Real Food’ entry; article text not available
- Tailscale disables state-file encryption and hardware attestation by default
- npm to implement staged publishing following turbulent shift from classic tokens