我有本土的 CalDAV 实现，通常可以正常工作，但有一个问题。有数百个日历的客户端通过移动网络同步。每次 iCalendar 以 depth=1 询问 PROPFIND 时，我的服务器必须回答完整的日历列表，给出巨大的响应，有时由于移动网络不稳定而失败。
我想将响应拆分成更小的块（例如每个响应 30 个）会有所帮助，但我不知道这是否真的可能。
所以问题是 - 我可以强制客户通过 N 个日历块在连续请求中 PROPFIND 日历吗？
问问题
254 次
3 回答
1
不，没有对此达成一致的标准。
话虽这么说：（1）您是否压缩了响应？(2) 你看过https://datatracker.ietf.org/doc/html/draft-murchison-webdav-prefer-05吗？
于 2013-11-25T10:12:02.260 回答
0
当您说“100 个日历”时，您的意思是“100 个事件”吗？因为包含 100 个项目的 PROPFIND 响应实际上并不大，这是完全正常的。但很多时候，日历中的事件列表可能很大。但苹果通常会做相当好的 caldav 客户端，他们应该在适当的日期范围内执行 REPORT 请求，这样他们就不会收到太多事件。
您的 Caldav 服务器可能没有实现完整的报告范围，因此客户端正在回退到更简单的方法。
于 2013-11-25T23:48:38.937 回答
0
正如布拉德所提到的，您需要区分日历数量和日历中的事件数量。
拥有数百个日历是非常不寻常的，但这应该还可以。具有 100 个结果的 PROPFIND 并不算大。另请注意 CTag，如果可用，您首先知道是否需要同步日历内容。
很可能您实际上是在询问一些包含大量事件的日历，可能是数千个。在这种情况下，日历上用于获取 ETag 以检查更改的 PROPFIND:1 可能会变得很大且很慢。（无论如何，请确保您确实支持 Accept-Encoding：gzip 和 Brief:T）。
对于这种情况，有一个 RFC 解决方案：RFC 6578。使用同步报告，您只需返回自上次同步以来更改的记录。它受 iOS 和 iCal 支持。该规范还支持批处理（在 RFC 中称为截断），但这并没有在所有客户端中实现。
于 2014-02-27T00:44:42.420 回答