这篇文章探讨了WebDAV协议在Go语言实现中的诸多挑战，包括现有实现的问题、RFC标准的不完善、逆向工程的困难、Go语言处理XML的复杂性，以及标准在实际应用中往往只是建议而非强制规范的情况。

WebDAV的多重困境：标准与实践的鸿沟

项目背景

在开发Homechart产品时，我们尝试实现WebDAV/CalDAV客户端和服务端，原以为这是项简单任务——毕竟这是21世纪初就已标准化的协议。然而现实给了我们沉重一击。

技术探索历程

1. 现有实现的局限

   • 评估了Go语言现有的go-webdav库，发现其缺乏集合同步等关键功能
   • 接口设计与我们的数据模型不匹配，决定自主开发核心功能

2. RFC标准的混乱

   • 原始标准RFC 2518被RFC 4918部分取代，但未明确说明替代范围
   • 存在7个扩展RFC，最终仅需实现日历事件的CRUD功能
   • 耗费一个月尝试完整实现后放弃，因标准包含过多无用历史包袱

3. 逆向工程实践

   • 通过分析主流客户/服务端的实际通信：
     • 客户端：Apple Calendar、DavX、Thunderbird
     • 服务端：iCloud、Google Calendar、Radicale
   • 使用Wireshark抓包发现需同时解析HTTP头和消息体

4. XML处理方案

   • Go原生XML库体验糟糕
   • 开发了类DOM操作的封装库，示例代码： go davDisplayName.SetValue("name") davOwner.AddChild(davHref.SetValue("http://example.com"))

标准与实践的冲突

• 服务端问题：

  • Apple/Google仅实现RFC子集，且功能声明与实际不符
  • 缺乏明确的支持清单，依赖HTTP能力声明（但常不准确）

• 客户端乱象：

  • 同步机制实现参差不齐
  • Apple Calendar拒绝使用高效的sync-collection，坚持ctags/etags方案

开发者困境

作为小型开发商，必须严格遵循标准才能保证兼容性，而科技巨头却可以随意偏离标准。开源社区中充斥着针对Google等特定实现的workaround代码，这种双重标准令人沮丧。

结论

除非你愿意牺牲理智，否则不要尝试开发WebDAV/CalDAV库——标准文档只是美好的幻想，现实世界充满各家厂商的私设藩篱。

（原文发布于2026年1月7日，Candid Development博客）

总结评论内容：

1. 对WebDAV协议的批评观点：

• 认为协议过时且实现混乱："I honestly didn't know WevDAV was still a thing. It seems like a nightmare"(kayo_20211030)
• 指出客户端实现问题："Mounting WebDAV...HOW it works: files are downloaded in full before program can access them"(112233)

2. 对WebDAV协议的辩护观点：

• 认为协议仍具实用价值："I'm using WebDAV...on a daily basis and...it works"(utopiah)
• 对比S3协议优势："it's already better than S3 for most use case"(mickael-kerjean)

3. 开发实践讨论：

• 推荐使用现有成熟库："PHP-based Sabre/DAV...does as good or nearly as good a job"(eddieroger)
• 建议改进方法："Why not download the most popular DAV libraries...have AI analyze"(didip)

4. 标准规范问题：

• 批评RFC分散："This is a major complaint I have with RFCs"(thayne)
• 认为部分实现即可："On not implementing half the RFCs, this is almost always true"(tracker1)

5. 替代方案讨论：

• 提到新方案："Recently I have abandoned in favor of AWS Mountpoint"(aurumque)
• 表达对新协议的期待："I would love to see something new"(BoredPositron)