拆分 caldav PROPFIND 响应太大时答案

【问题标题】：Split caldav PROPFIND response when it is too large拆分 caldav PROPFIND 响应太大时
【发布时间】：2013-11-25 09:05:56
【问题描述】：

我有本地的 CalDAV 实现，通常可以正常工作，但有一个问题。有数百个日历的客户端通过移动网络同步。每次 iCalendar 以 depth=1 询问 PROPFIND 时，我的服务器必须回答完整的日历列表，给出巨大的响应，有时由于不稳定的移动网络而失败。

我想将响应分成更小的块（例如每个响应 30 个）会有所帮助，但我不知道这是否真的可能。

所以问题是 - 我可以强制客户端通过 N 个日历块在连续请求中 PROPFIND 日历吗？

【问题讨论】：

标签： mobile webdav icalendar 3g caldav

【解决方案1】：

不，对此没有公认的标准。

话虽这么说：（1）您是否压缩了响应？ (2)你看过https://datatracker.ietf.org/doc/html/draft-murchison-webdav-prefer-05吗？

【讨论】：

【解决方案2】：

当您说“100 个日历”时，您的意思是“100 个事件”吗？因为包含 100 个项目的 PROPFIND 响应实际上并不大，这是完全正常的。但很多时候，日历中的事件列表可能很大。但苹果通常会做相当好的 caldav 客户端，他们应该在适当的日期范围内执行 REPORT 请求，这样他们就不会收到太多事件。

您的 Caldav 服务器可能没有实现全部范围的报告，因此客户端正在回退到更简单的方法。

【讨论】：

不幸的是，正如我所说，日历。所以 REPORT 不是我的选择。
哇，你们需要的日历少了！ :)

【解决方案3】：

正如 brad 所说，您需要区分日历数和日历中的事件数。

拥有数百个日历是非常不寻常的，但这应该没问题。具有 100 个结果的 PROPFIND 并不算大。另请注意 CTag，如果可用，您首先知道是否需要同步日历内容。

您很可能实际上是在询问一些包含大量事件的日历，可能有数千个。在这种情况下，日历上的 PROPFIND:1 抓取 ETags 以检查更改可能会变得很大且很慢。（无论如何，请确保您确实支持 Accept-Encoding：gzip 和 Brief:T）。

对于这种情况，有一个 RFC 解决方案：RFC 6578。使用同步报告，您只需返回自上次同步以来更改的记录。它受 iOS 和 iCal 支持。该规范还支持批处理（在 RFC 中称为截断），但并非在所有客户端中都实现。

【讨论】：

其实是很多日历的问题。即使用户不想同步它，我们也会为平台上的每个项目创建日历条目。我们只是没想到有人会在一个帐户中创建数百个项目。现在我们只让用户选择他们想要同步的日历（项目），因此同步日历的数量下降到十几个以下。
好的。但是同步日历是一个单一的 PROPFIND 调用，所以应该没问题。这里重要的是在获取日历时也要获取 CTag。这样您就不需要在每个日历中进行另一个查询，无论是否更改。
没有问题，因为我在需要的地方实现了 ctags 和 etags。 iPhone 未能执行第一个同步序列，因此无需担心任何进一步的请求。