1

現在、システムに「単純な」読み取り専用 CALDAV インターフェイスを実装しようとしています。しかし、同期プロトコルと CALDAV クライアントは頭を悩ませます。

私が使用する主なテスト クライアントは macos-calendar (sierra) です。初期ハンドシェイク (DAV 原則、カレンダー検索) とデータの初期ロードが機能しています。REPORT:calendar-query リクエストを受け取ります。問題は、初期ロード後の増分同期です。次の 2 つの方法があります。

  • WebSync 拡張機能 (REPORT:sync-collection および sync-token prop) を介して、ここでの私の主な問題は、サーバーからの同期トークンのプロビジョニングが私のシステムでは簡単ではないことです。変更と新しいデータは問題ではありませんが、物理的な削除 (ユーザー コンテキストにはまだ記録されていません) と、グループおよび/またはロールの割り当ての範囲の変更です。複雑なケースでは同期トークンを無効にし、同期コレクションなしでクライアントをリセットすることを検討する必要があるでしょうか? 厄介な回避策は、クライアントに送信されたカレンダー アイテム ID を保持し、各要求でそれらの存在を確認し、必要に応じて、削除された/スコープ外のカレンダー アイテムごとに見つからないという応答を返すことです。しかし、これはクライアントの状態をサーバーに保存することを意味し、正しく聞こえず、エラーが発生しやすい可能性があります。

  • 基本的なプロトカル同期 (REPORT:calendar-query に応答し、propfind (深さ = 1) は webdav-sync をアクティブに要求しない) を介して、これは原則として、新規および変更されたデータに対して既に機能しています。ただし、macos-calendar は、コレクション応答 (深さ = 1 の propfind) の一部ではないアイテムを削除しません。プロトコルによると、クライアントは削除されたアイテムを特定して削除する必要がありますが、私の場合はそうしません。ここに何かアイデアはありますか?私のシステムでは、現在、このアプローチを使用するのが理想的ですが、パフォーマンスは理想的なものではないかもしれません.

ios-Calendar を使用すると、別の問題に直面します。

  • ネットワーク内の要求が来て応答されると、最初のハンドシェイクが何らかの形で機能します。

  • しかし、オプション応答の Allow-header にも提供していないため、403 で応答する MKCALENDAR 要求が (項目のカレンダークエリまたは propfind の代わりに) 来ています。リクエストは次のようになります。

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>

  • その後何も起きていません。

  • これも経験した人いますか?resource-type として calendar-collection があるのに、ios-calendar が mkcalendar を実行しようとするのはなぜですか?

Thunderbird ライトニングの場合:

  • calendar-collection との最初のハンドシェイクが機能しています

  • アイテムの propfind-and multiget リクエストは、iCal-Items で応答されます。

  • しかし、それらは表示されず、受け取ったエラーログには次のように表示されます:

  • 警告: CalDAV: 取得に失敗しました: CalDAV: エラー: デバッグ プロキシのカレンダー データをフェッチするステータス 200 を取得しました、null

  • (ドイツ語のテキスト: エラー コード: 0x80004005) 警告: カレンダのためにデータを収集する: デバッグ プロキシ。Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren. フェーラーコード: 0x80004005。詳細: CalDAV: Error: got status 200 fetching calendar data for Debug Proxy, null

  • (ドイツ語のテキスト: エラー コード: READ_FAILED) 警告: カレンダのデータを参照してください: デバッグ プロキシ。Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren. フェーラーコード: READ_FAILED。詳細:

  • HTTP チャネル リスナーの OnDataAvailable 契約違反

  • 同様の応答は macos-calendar で動作していますが、エンコードの問題でしょうか?

どんなヒントでも大歓迎です!

4

2 に答える 2

1

Thunderbird/Lightning の場合は、高度な構成エディターをオンにして再起動することをお勧めしますcalendar.debug.logcalendar.debug.log.verboseで見つけることができますOptions > Advanced > General > Config Editor。これにより、より詳細な http リクエストと、何が失敗したかに関する情報が得られます。また、リモート デバッガーを接続してネットワーク モニターを確認したり、コードにブレークポイントを設定したりすることもできます。

Thunderbird/Lightning では、以前のバージョンと現在のバージョンの webdav-sync ドラフトを組み合わせて使用​​していることに注意してください。非常に一般的であるため、エラー メッセージから多くを語ることはできませんが、結果に予期しないものがあるように見えます。

おそらく、既存のサーバー ( sabre/davなど) とクライアント間のハンドシェイクを比較して、自分の通信と相手の通信の違いを確認することは理にかなっています。

また、サーバーの相互運用性をチェックする AppleのCalDAVTesterにも興味があるかもしれません。ただし、さまざまなアップル固有のテストが含まれていることに注意してください。CalConnectの人々はApple と協力して、より一般的に使用できるようにし、Apple 固有のテストを分割しています。サーバーが読み取り専用であるため、すべてが機能するとは思わないでください。ただし、特定のテストの修正を探すことはできます。

于 2016-10-13T11:11:40.817 に答える