Синхронизация протокола CalDAV и поведение разных клиентов

Question

В настоящее время я пытаюсь реализовать "простой" CALDAV-интерфейс только для чтения для системы. Но протокол синхронизации и CALDAV-клиенты доставляют мне некоторые головные боли.

Основным тестовым клиентом, который я использую, является macos-calendar (sierra). Начальное рукопожатие (принцип DAV, поиск по календарю) и начальная загрузка данных работают. Я получаю несколько отчетов: запросы календаря. Проблема заключается в добавочной синхронизации после начальной загрузки. Есть два подхода:

• Через расширение WebSync (REPORT:sync-collection и sync-token prop) моя главная проблема заключается в том, что предоставление sync-токена с сервера не является тривиальным в моей системе. Изменения и новые данные - это не проблема, а физическое удаление (еще не зарегистрированное в пользовательском контексте) и изменения в области назначений групп и / или ролей. Может быть, мне нужно рассмотреть, чтобы в сложных случаях аннулировать токен синхронизации и позволить клиенту выполнить сброс без синхронизации? Неприятным обходным решением может быть сохранение идентификаторов элементов календаря, отправленных клиенту, и проверка каждого запроса на их наличие и, если необходимо, ответы на них с не найденным для каждого элемента календаря, удаленного или находящегося за пределами области видимости. Но это будет означать, что я храню клиентское состояние на сервере, который не звучит правильно и может быть подвержен ошибкам.

• Посредством базовой синхронизации протоколов (ответ на ОТЧЕТ: календарь-запрос и propfind (глубина =1) не запрашивают никакой активной веб-синхронизации), это также в принципе уже работает для новых и измененных данных. Но макос-календарь не удаляет элементы, которые не являются частью ответа коллекции (propfind with deep =1). Согласно протоколу клиент должен определить удаленные элементы и удалить их, но в моем случае этого не происходит. Есть идеи здесь? Для моей системы в настоящее время было бы идеально использовать этот подход, хотя производительность может быть не идеальной.

С ios-Calendar я столкнулся с еще одной проблемой:

• Начальное рукопожатие как-то работает, поскольку запросы в сети приходят и отвечают.

• Но затем приходит запрос MKCALENDAR (вместо запроса календаря или propfind для элементов), который отвечает 403, поскольку я также не предоставляю его в заголовке Allow-ответа ответа опций. запрос выглядит так:

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, хотя у меня есть коллекция календаря как тип ресурса?

С Молнией Громовой Птицы:

• Начальное рукопожатие с календарем-сборником работает

• На запрос propfind и multiget для элементов отвечает iCal-Items.

• Но они не отображаются и в журнале ошибок я получаю:

• Предупреждение: CalDAV: сбой: CalDAV: ошибка: получен статус 200 при получении данных календаря для отладочного прокси, ноль

• (текст на немецком языке: код ошибки: 0x80004005) Предупреждение: Fehler beim Lesen von Daten für Kalender: отладочный прокси. Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren. Код Фехлера: 0x80004005. Beschreibung: CalDAV: Ошибка: получен статус 200 при извлечении данных календаря для отладочного прокси, ноль

• (текст на немецком языке: код ошибки: READ_FAILED) Предупреждение: Fehler beim Lesen von Daten für Kalender: отладочный прокси. Allerdings ist dieser Fehler wahrscheinlich vernachlässigbar, daher versucht das Programm fortzufahren. Код Fehler: READ_FAILED. Beschreibung:

• http канал Listener OnDataAvailable нарушение договора

• хотя похожий ответ работает и в макос-календаре - может ли это быть проблемой кодирования?

Любые намеки высоко ценятся!

Answer 1

Это действительно довольно широкий вопрос. Но позвольте мне обратиться к некоторым вещам:

Через расширение WebSync (REPORT:sync-collection и sync-token prop) моя главная проблема заключается в том, что предоставление sync-токена с сервера не является тривиальным в моей системе

Даже если вам тяжело, вы должны действительно попытаться придумать что-то здесь. Даже если это означает хранение некоторой дополнительной информации на сервере. Синхронизация более эффективна. (Идея: может быть, вы можете хотя бы установить флаг, когда что-то действительно будет удалено, и только тогда срок действия токена синхронизации истечет?)

Посредством базовой протокольной синхронизации (ответьте на REPORT:calendar-query и propfind (deep =1))

Который из, calendar-range-query или же PROPFIND? Совершенно разные вещи...

это также работает в принципе для новых и измененных данных. Но макос-календарь не удаляет элементы, которые не являются частью ответа коллекции (propfind with deep =1).

Если мы говорим о запросе календарного диапазона, клиент не может предварительно удалить элементы, так как он не знает, покинули ли они диапазон (против удаления).

С PROPFIND это должно сделать это. Если у вас есть доказательства этого, возможно, создайте еще один вопрос со всеми соответствующими деталями.

С ios-Calendar я сталкиваюсь с другой проблемой: ... приходит запрос MKCALENDAR...

Это, вероятно, означает, что он не может найти календарь планирования по умолчанию, никакого календаря вообще, ни с соответствующим свойством типа компонента. Или все то же самое для задач (приложение напоминаний, та же учетная запись). Какова полезная нагрузка MKCALENDAR? Трудно диагностировать без подробностей, если вы не можете это выяснить, задайте конкретный вопрос по этому вопросу со всеми соответствующими деталями (например, XML, который вы отправляете в ответ на домашний запрос).

Молния Громовой Птицы

Не могу много сказать об этом, возможно, многое зависит от версии и того, какие расширения вы используете. AFAIK многие люди используют расширения ScalableOGo Thunderbird, чтобы получить правильный Cal/CardDAV с Thunderbird.

Answer 2

Для Thunderbird/Lightning вы можете включить calendar.debug.log а также calendar.debug.log.verbose в расширенном редакторе конфигурации и перезапустите. Вы можете найти это в Options > Advanced > General > Config Editor, Это даст вам более подробные http запросы и информацию о том, что не удалось. Вы также можете подключить удаленный отладчик и посмотреть на сетевой монитор или установить точки останова в коде.

Что касается Thunderbird/Lightning, обратите внимание, что мы используем сочетание предыдущих и текущих версий черновика webdav-sync. Я не могу много сказать из сообщения об ошибке, так как оно очень общее, но похоже, что в результатах есть что-то неожиданное.

Может быть, имеет смысл сравнить рукопожатие между существующим сервером (например, Sabre / DAV) и клиентом, а затем посмотреть, в чем разница между вашим общением и их.

Также вас может заинтересовать CalDAVTester от Apple, который проверяет совместимость серверов. Обратите внимание, что он содержит различные тесты для яблок. Сотрудники CalConnect работают вместе с Apple, чтобы сделать его более удобным для использования и разделить специфичные для Apple тесты. Поскольку ваш сервер предназначен только для чтения, не ожидайте, что все будет работать, но вы можете охотиться за исправлением определенных тестов.