分裂caldav PROPFIND响应过大时

Question

我自己开发的CalDAV实现通常运行良好，但有一个问题。有数百个日历的客户端通过移动网络进行同步。每次iCalendar用depth=1询问PROPFIND时，我的服务器必须回答全部日历列表，给出巨大的响应，有时由于移动网络不稳定而失败。

我想将响应分割成较小的块(比如每个响应30次)会有帮助，但我不知道是否真的有可能。

所以问题是--我可以强迫客户端在连续的N个日历块的请求中使用PROPFIND日历吗？

Answer 1

不，还没有一致同意的标准。

也就是说：(1)您是否压缩了响应？(2)您看过https://datatracker.ietf.org/doc/html/draft-murchison-webdav-prefer-05吗？

Answer 2

当你说“百年历”时，是指“百年一遇”吗？因为PROPFIND对100多个项目的响应实际上并不大，这是完全正常的。但通常情况下，日历中的事件列表可能很大。但是苹果通常做的很好的caldav客户端，他们应该做报告请求与适当的日期范围，这样他们就不会有太多的事件。

您的Caldav服务器可能没有实现所有的报告，因此客户端回到了一种更简单的方法。

Answer 3

正如布拉德所提到的，您需要区分日历的数量和日历中事件的数量。

拥有数以百计的日历是非常不寻常的，但这应该是可以的。有100个结果的PROPFIND并不是太大。还要注意CTag，如果这是可用的，那么首先您知道是否需要同步日历内容。

最有可能的情况是，您实际上是在询问一些包含大量事件的日历，可能有数千个。在这种情况下，PROPFIND:1在日历上抓取ETags以检查更改可能变得很大&缓慢。(在任何情况下，请确保您确实支持接受-编码: gzip和简要:t)。

对于这种情况，有一个RFC'd解决方案: RFC 6578。对于同步报告，您只需要返回自上次同步后更改的记录。它得到iOS和iCal的支持。规范还支持批处理(在RFC中称为截断)，但这并不是在所有客户机中实现的。