我有自己开发的CalDAV实现，它通常运行良好，但有一个问题。有数百个日历的客户端通过移动网络进行同步。每次iCalendar询问深度=1的PROPFIND时，我的服务器都必须用完整的日历列表来回答，这些日历会给出巨大的响应，有时会因为移动网络不稳定而失败。
我想把响应分成小块（比如每个响应30个）会有所帮助，但我不知道这是否真的可能。
所以问题是——我可以通过N个日历块强制客户端在连续请求中使用PROPFIND日历吗？
不，没有达成一致的标准。
话虽如此：（1）你是否压缩了响应？（2） 你看了吗https://datatracker.ietf.org/doc/html/draft-murchison-webdav-prefer-05?
当你说"100个日历"时，你的意思是"100个事件"吗？因为一个包含100个项目的PROPFIND响应实际上并不大，这很正常。但通常情况下，日历中的事件列表可能很大。但苹果通常做得很好的caldav客户，他们应该在适当的日期范围内处理REPORT请求，这样他们就不会收到太多事件。
您的Caldav服务器可能无法实现全部报告，因此客户端只能采用更简单的方法。
正如brad所提到的，您需要区分日历的数量和日历中的事件数量。
拥有数百个日历是很不寻常的，但也可以。一个有100个结果的PROPFIND并不算太大。还要注意CTag，如果它可用，您首先就知道是否需要同步日历内容。
最有可能的是，你实际上在询问一些包含大量事件的日历，可能有数千个。在这种情况下，PROPFIND:1在日历上抓取ETag以检查更改可能会变得很大；缓慢的（在任何情况下，请确保您确实支持Accept-Encoding:gzip和Brief：T）。
对于这种情况，有一个RFC的解决方案：RFC 6578。使用同步报告，您只需要返回自上次同步以来更改的记录。它受到iOS和iCal的支持。该规范还支持批处理（在RFC中称为截断），但这并不是在所有客户端中都实现的。