不同客户端的 CalDAV 协议同步和行为
CalDAV protocol synchronization and behavior of different clients
我目前正在尝试为系统实现一个“简单的”只读 CALDAV-interface。但是同步协议和 CALDAV-clients 让我有些头疼。
我使用的主要测试客户端是macos-calendar (sierra)。
初始握手（DAV 原理、日历查找）和初始数据加载正在运行。我收到一些 REPORT:calendar 查询请求。
问题是初始加载后的增量同步。有两种方法：
通过 WebSync-extension（报告：sync-collection 和 sync-token 支持）
我这里的主要问题是从服务器配置 sync-token 在我的系统中不是微不足道的。更改和新数据不是问题，但物理删除（尚未登录用户上下文）和组范围内的更改- and/or role-assignments。也许我需要考虑在复杂情况下使 sync-token 无效并让客户端在没有 sync-collection 的情况下重新启动？
一个糟糕的解决方法可能是保留发送给客户端的日历项 ID，并检查每个请求是否存在，并在必要时响应每个 deleted/out 范围日历项未找到。但这意味着我将 client-state 存储在服务器上，这听起来不正确并且可能容易出错。
通过基本协议同步（响应 REPORT:calendar-query 和 propfind (depth=1) requests no webdav-sync active）
这在原则上也适用于新的和更改的数据。但是 macos-calendar 不会删除不属于 collection 响应的项目（深度为 1 的 propfind）。根据协议，客户端应确定已删除的项目并将其删除，但在我的情况下不会这样做。这里有什么想法吗？
对于我的系统，目前使用这种方法是理想的，尽管性能可能不是理想的方法。
ios-Calendar 我面临另一个问题：
初始握手以某种方式工作，因为网络中的请求即将到来并得到答复。
但是 MKCALENDAR 请求即将到来（而不是 calendar-query 或项目的 propfind），它用 403 回答，因为我也没有在 Allow-header 中提供它选项响应。请求看起来像这样：
MKCALENDAR /services/cal/_userid/220EDB4A-F00C-41C9-B78F-10781BBA77E4/ HTTP/1.1
Host: 127.0.0.1:8003
Content-Type: text/xml
User-Agent: iOS/10.0.1 (14A403) dataaccessd/1.0
<?xml version="1.0" encoding="UTF-8"?>
<B:mkcalendar xmlns:B="urn:ietf:params:xml:ns:caldav">
<A:set xmlns:A="DAV:">
<A:prop>
<B:calendar-free-busy-set>
<NO/>
</B:calendar-free-busy-set>
<D:calendar-order xmlns:D="http://apple.com/ns/ical/">1</D:calendar-order>
<A:displayname>Kalender</A:displayname>
<B:calendar-timezone>BEGIN:VCALENDAR
...deleted....
</B:calendar-timezone>
<B:supported-calendar-component-set>
<B:comp name="VEVENT"/>
</B:supported-calendar-component-set>
</A:prop>
</A:set>
</B:mkcalendar>
之后没有任何事情发生。
有人也遇到过这种情况吗？为什么 ios-calendar 尝试做一个 mkcalendar 虽然我有一个 calendar-collection 作为 resource-type?
使用雷鸟闪电：
与 calendar-collection 的初始握手有效
一个 propfind-and 项的 multiget 请求被 iCal-Items 回答。
但它们没有显示，在我收到的错误日志中：
警告：CalDAV：获取失败：CalDAV：错误：获取状态 200 获取调试代理的日历数据，null
（德语文本：错误代码：0x80004005）警告：Fehler beim Lesen von Daten für Kalender：调试代理。 Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren.费勒代码：0x80004005。说明：CalDAV：错误：获取调试代理的获取日历数据的状态 200，null
（德语文本：错误代码：READ_FAILED）警告：Fehler beim Lesen von Daten für Kalender：调试代理。 Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren.费勒代码：READ_FAILED。评论：
http 通道侦听器 OnDataAvailable 违约
虽然在 macos-calendar 中也有类似的响应——会不会是编码问题？
非常感谢任何提示！
这确实是一个相当宽泛的问题。但让我尝试解决一些问题：
Via WebSync-extension (REPORT:sync-collection and sync-token prop) my main issue here is that provisioning the sync-token from the server is not trivial in my system
即使这对你来说很难，你也应该在这里尝试想出点什么。即使这意味着在服务器上存储一些额外的信息。同步收集效率更高。
（想法：也许你至少可以在实际删除某些内容时设置一个标志，然后才使同步令牌过期？）
Via basic protocal synchronization (respond to REPORT:calendar-query and propfind (depth=1))
calendar-range-query 或 PROPFIND 哪个？完全不同的东西...
this is also working already in principle for new and changed data. But the macos-calendar doesnt remove items which are not part the collection response (propfind with depth=1).
如果我们谈论的是日历范围查询，客户端无法主动删除项目，因为它不知道它们是否刚刚离开范围（相对于被删除）。
对于 PROPFIND 它应该这样做。如果您有证据证明它没有，也许可以创建另一个包含所有相关详细信息的问题。
With ios-Calendar i face another issue: ... a MKCALENDAR request is coming ...
这可能意味着它找不到默认的日程安排日历，根本没有日历，none 具有适当的组件类型 属性。或者对于待办事项（提醒应用程序，同一个帐户）都是一样的。 MKCALENDAR 的有效载荷是多少？
难以诊断 w/o 详细信息，如果您无法弄清楚，请就此提出一个具体问题，并提供所有相关详细信息（例如，您发送的 XML 以响应主页查询）。
Thunderbird Lightning
对此不能说太多，可能在很大程度上取决于版本和您使用的扩展。据我所知，许多人使用 ScalableOGo Thunderbird 扩展来获得正确的 Cal/CardDAV Thunderbird。
对于 Thunderbird/Lightning，您可能需要在高级配置编辑器中打开 calendar.debug.log 和 calendar.debug.log.verbose，然后重新启动。您可以在 Options > Advanced > General > Config Editor 中找到它。这将为您提供更详细的 http 请求和有关失败内容的信息。您还可以连接 remote debugger and look at the network monitor, or set breakpoints in the code.
Thunderbird/Lightning 请注意，我们混合使用了 webdav-sync 草稿的先前版本和当前版本。我不能从错误消息中说出太多，因为它非常笼统，但看起来结果中确实有一些意想不到的东西。
也许比较现有服务器（如sabre/dav）和客户端之间的握手是有意义的，然后看看你和他们的通信之间的区别在哪里。
此外，您可能对 CalDAVTester from Apple, which checks server interoperability. Note however that it does contain various apple specific tests. The folks at CalConnect 正在与 Apple 合作以使其更普遍可用并拆分特定于 Apple 的测试感兴趣。鉴于您的服务器是只读的，不要指望一切正常，但您可以寻找修复特定测试的方法。
我目前正在尝试为系统实现一个“简单的”只读 CALDAV-interface。但是同步协议和 CALDAV-clients 让我有些头疼。
我使用的主要测试客户端是macos-calendar (sierra)。 初始握手（DAV 原理、日历查找）和初始数据加载正在运行。我收到一些 REPORT:calendar 查询请求。 问题是初始加载后的增量同步。有两种方法：
通过 WebSync-extension（报告：sync-collection 和 sync-token 支持） 我这里的主要问题是从服务器配置 sync-token 在我的系统中不是微不足道的。更改和新数据不是问题，但物理删除（尚未登录用户上下文）和组范围内的更改- and/or role-assignments。也许我需要考虑在复杂情况下使 sync-token 无效并让客户端在没有 sync-collection 的情况下重新启动？ 一个糟糕的解决方法可能是保留发送给客户端的日历项 ID，并检查每个请求是否存在，并在必要时响应每个 deleted/out 范围日历项未找到。但这意味着我将 client-state 存储在服务器上，这听起来不正确并且可能容易出错。
通过基本协议同步（响应 REPORT:calendar-query 和 propfind (depth=1) requests no webdav-sync active） 这在原则上也适用于新的和更改的数据。但是 macos-calendar 不会删除不属于 collection 响应的项目（深度为 1 的 propfind）。根据协议，客户端应确定已删除的项目并将其删除，但在我的情况下不会这样做。这里有什么想法吗？ 对于我的系统，目前使用这种方法是理想的，尽管性能可能不是理想的方法。
ios-Calendar 我面临另一个问题：
初始握手以某种方式工作，因为网络中的请求即将到来并得到答复。
但是 MKCALENDAR 请求即将到来（而不是 calendar-query 或项目的 propfind），它用 403 回答，因为我也没有在 Allow-header 中提供它选项响应。请求看起来像这样：
MKCALENDAR /services/cal/_userid/220EDB4A-F00C-41C9-B78F-10781BBA77E4/ HTTP/1.1
Host: 127.0.0.1:8003
Content-Type: text/xml
User-Agent: iOS/10.0.1 (14A403) dataaccessd/1.0
<?xml version="1.0" encoding="UTF-8"?>
<B:mkcalendar xmlns:B="urn:ietf:params:xml:ns:caldav">
<A:set xmlns:A="DAV:">
<A:prop>
<B:calendar-free-busy-set>
<NO/>
</B:calendar-free-busy-set>
<D:calendar-order xmlns:D="http://apple.com/ns/ical/">1</D:calendar-order>
<A:displayname>Kalender</A:displayname>
<B:calendar-timezone>BEGIN:VCALENDAR
...deleted....
</B:calendar-timezone>
<B:supported-calendar-component-set>
<B:comp name="VEVENT"/>
</B:supported-calendar-component-set>
</A:prop>
</A:set>
</B:mkcalendar>
之后没有任何事情发生。
有人也遇到过这种情况吗？为什么 ios-calendar 尝试做一个 mkcalendar 虽然我有一个 calendar-collection 作为 resource-type?
使用雷鸟闪电：
与 calendar-collection 的初始握手有效
一个 propfind-and 项的 multiget 请求被 iCal-Items 回答。
但它们没有显示，在我收到的错误日志中：
警告：CalDAV：获取失败：CalDAV：错误：获取状态 200 获取调试代理的日历数据，null
（德语文本：错误代码：0x80004005）警告：Fehler beim Lesen von Daten für Kalender：调试代理。 Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren.费勒代码：0x80004005。说明：CalDAV：错误：获取调试代理的获取日历数据的状态 200，null
（德语文本：错误代码：READ_FAILED）警告：Fehler beim Lesen von Daten für Kalender：调试代理。 Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren.费勒代码：READ_FAILED。评论：
http 通道侦听器 OnDataAvailable 违约
虽然在 macos-calendar 中也有类似的响应——会不会是编码问题？
非常感谢任何提示！
这确实是一个相当宽泛的问题。但让我尝试解决一些问题：
Via WebSync-extension (REPORT:sync-collection and sync-token prop) my main issue here is that provisioning the sync-token from the server is not trivial in my system
即使这对你来说很难，你也应该在这里尝试想出点什么。即使这意味着在服务器上存储一些额外的信息。同步收集效率更高。 （想法：也许你至少可以在实际删除某些内容时设置一个标志，然后才使同步令牌过期？）
Via basic protocal synchronization (respond to REPORT:calendar-query and propfind (depth=1))
calendar-range-query 或 PROPFIND 哪个？完全不同的东西...
this is also working already in principle for new and changed data. But the macos-calendar doesnt remove items which are not part the collection response (propfind with depth=1).
如果我们谈论的是日历范围查询，客户端无法主动删除项目，因为它不知道它们是否刚刚离开范围（相对于被删除）。
对于 PROPFIND 它应该这样做。如果您有证据证明它没有，也许可以创建另一个包含所有相关详细信息的问题。
With ios-Calendar i face another issue: ... a MKCALENDAR request is coming ...
这可能意味着它找不到默认的日程安排日历，根本没有日历，none 具有适当的组件类型 属性。或者对于待办事项（提醒应用程序，同一个帐户）都是一样的。 MKCALENDAR 的有效载荷是多少？
难以诊断 w/o 详细信息，如果您无法弄清楚，请就此提出一个具体问题，并提供所有相关详细信息（例如，您发送的 XML 以响应主页查询）。
Thunderbird Lightning
对此不能说太多，可能在很大程度上取决于版本和您使用的扩展。据我所知，许多人使用 ScalableOGo Thunderbird 扩展来获得正确的 Cal/CardDAV Thunderbird。
对于 Thunderbird/Lightning，您可能需要在高级配置编辑器中打开 calendar.debug.log 和 calendar.debug.log.verbose，然后重新启动。您可以在 Options > Advanced > General > Config Editor 中找到它。这将为您提供更详细的 http 请求和有关失败内容的信息。您还可以连接 remote debugger and look at the network monitor, or set breakpoints in the code.
Thunderbird/Lightning 请注意，我们混合使用了 webdav-sync 草稿的先前版本和当前版本。我不能从错误消息中说出太多，因为它非常笼统，但看起来结果中确实有一些意想不到的东西。
也许比较现有服务器（如sabre/dav）和客户端之间的握手是有意义的，然后看看你和他们的通信之间的区别在哪里。
此外，您可能对 CalDAVTester from Apple, which checks server interoperability. Note however that it does contain various apple specific tests. The folks at CalConnect 正在与 Apple 合作以使其更普遍可用并拆分特定于 Apple 的测试感兴趣。鉴于您的服务器是只读的，不要指望一切正常，但您可以寻找修复特定测试的方法。