TL;DR
A small team attempted to implement a WebDAV/CalDAV client and server in Go for Homechart and found the ecosystem messier than the specs imply. They abandoned a full RFC-driven implementation, reverse-engineered real clients/servers, wrapped Go's XML handling, and noted wide divergence from standards among major providers.
What happened
The Homechart team set out to write both a WebDAV/CalDAV client and server in Go, expecting a straightforward build from published specs. After evaluating existing Go libraries they found go-webdav missing key features such as server-side collection synchronization and incompatible interfaces, so they proceeded to implement their own. Reading RFCs (including RFC 2518 and RFC 4918) proved time-consuming and full of legacy complexity; after nearly a month trying to follow the full standards they scaled back to focus on calendar CRUD. They then reverse-engineered real-world clients and servers — capturing HTTP traffic with proxies and packet tools — to determine which requests and headers to support. To handle WebDAV’s loosely structured XML, they created a wrapper around Go’s XML tools to manipulate nodes more flexibly. Testing against live implementations revealed that major providers and clients diverge significantly from the RFCs, leading the authors to warn others about the difficulty of the task.
Why it matters
- Standards alone may not ensure interoperability when major providers diverge in practice.
- Smaller projects may need to reverse-engineer real-world behavior rather than rely solely on RFCs.
- Weaknesses in language tooling (Go’s XML APIs) can add engineering overhead for protocol implementations.
- Important features like collection synchronization may be absent in common libraries, forcing teams to build bespoke solutions.
Key facts
- Project aimed to implement WebDAV/CalDAV client and server in Go for Homechart.
- Existing Go implementation go-webdav lacked server-side collection synchronization and had interface mismatches.
- Authors reviewed RFCs including RFC 2518 and RFC 4918 but found full compliance impractical due to legacy cruft.
- After struggling with the RFCs for almost a month, the team switched to reverse engineering traffic from live clients and servers.
- Clients inspected included Apple Calendar, DavX, and Thunderbird; servers inspected included Apple iCloud, Google Calendar, and Radicale.
- HTTP bodies and headers both required close inspection to emulate real implementations.
- The team built a wrapper around Go’s XML handling to work with WebDAV’s unstructured XML payloads.
- Tests showed major providers often advertise capabilities generically and do not implement many RFC features.
- Apple Calendar prefers ctags and etags instead of the more efficient sync-collection for synchronization.
- Authors advise against taking on a WebDAV/CalDAV library project lightly due to implementation complexity.
What to watch next
- Whether go-webdav or other Go libraries add server-side collection synchronization or interface changes — not confirmed in the source.
- Any updates from major providers (Apple, Google) clarifying or aligning their WebDAV/CalDAV capabilities with RFCs — not confirmed in the source.
- Improvements or new libraries in Go that simplify XML node manipulation for protocols like WebDAV — not confirmed in the source.
Quick glossary
- WebDAV: An extension to HTTP that adds capabilities for managing resources on remote web servers, including create, move, and delete operations.
- CalDAV: An extension of WebDAV designed for access to calendar data, enabling clients to manage calendar events on servers.
- RFC: A Request for Comments document; a formal publication from the IETF that specifies protocols, standards, and practices for the internet.
- sync-collection: A WebDAV extension used to efficiently synchronize collections of resources between client and server.
- ctags/etags: Mechanisms that clients and servers use to detect changes to resources; ctags and etags provide simple change detection alternatives to sync-based approaches.
Reader FAQ
Did the team use an existing Go library?
They evaluated go-webdav but found it missing features and incompatible with their data model, so they implemented their own.
Did they implement the full WebDAV/CalDAV RFCs?
No. After about a month trying to follow the full specs, they narrowed scope to calendar CRUD because the full RFCs contained too much legacy complexity.
Which clients and servers did they test against?
They inspected Apple Calendar, DavX, Thunderbird and servers including Apple iCloud, Google Calendar, and Radicale.
Is the project code available?
not confirmed in the source
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: Writing a Client/Server in Go
- I hope WebDAV dies
- Integrating a self-hosted calendar solution
- Open-Source Productivity Apps in 2025: A Careful, …
Related posts
- RepoReaper: AST-aware, JIT-loading code-audit agent built in Python
- Meditation as Wakeful Relaxation: Unclenching Smooth Muscle Through Vasocomputation
- Developers might’ve stuck with Stack Overflow if community were kinder