2016-10-12 16 views
0

현재 시스템에 대해 "간단한"읽기 전용 CALDAV 인터페이스를 구현하려고합니다. 그러나 동기화 프로토콜과 CALDAV 클라이언트는 나에게 두통을 안겨줍니다.다른 클라이언트의 CalDAV 프로토콜 동기화 및 동작

내가 사용하는 주요 테스트 클라이언트는 macos-calendar (sierra)입니다. 데이터의 초기 핸드 셰이크 (DAV 원리, 일정 조회) 및 초기로드가 작동 중입니다. 몇 가지 REPORT : 달력 쿼리 요청을 받았습니다. 초기로드 후 증분 동기화가 문제입니다.

  • 통해 WebSync - 확장 (REPORT : 동기화 수집 및 동기화 토큰 소품) 여기 내 주요 문제는 서버에서 동기화 토큰을 프로비저닝하는 내 시스템의 사소한되지 않는 것입니다 두 가지가 있습니다. 변경 및 새 데이터는 문제가 아니지만 물리적 삭제 (사용자 컨텍스트에 아직 기록되지 않음) 및 그룹 및/또는 역할 할당의 범위가 변경되었습니다. 어쩌면 복잡한 경우에 sync-token을 무효화하고 sync-collection없이 클라이언트를 다시 설정하도록 고려해야합니까? 클라이언트에 보내는 일정 항목 ID를 유지하고 각 요청에 대한 존재 여부를 확인하고 필요한 경우 삭제/범위를 벗어난 일정 항목에서 찾을 수없는 항목으로 응답하는 것이 좋을 수 있습니다. 그러나 이것은 클라이언트의 상태를 서버에 저장한다는 의미 일 것이고, 서버는 정상적으로 작동하지 않으며 오류가 발생하기 쉽습니다.

  • 기본 프로토 콜 동기화 (달력에 대한 응답 : calendar-query 및 propfind (depth = 1) 요청에 대한 webdav-sync 활성 없음) 이것은 새로운 데이터와 변경된 데이터에 대해 원칙적으로 이미 작동합니다. 그러나 macos-calendar는 수집 응답에 포함되지 않는 항목을 제거하지 않습니다 (깊이 = 1로 propfind). 프로토콜에 따르면 클라이언트는 삭제 된 항목을 결정하고 제거해야하지만 내 경우에는 그렇지 않습니다. 어떤 아이디어가 있습니까? 내 시스템의 경우 현재 성능이 이상적인 것은 아니지만이 방법을 사용하는 것이 이상적입니다. IOS-달력

나는 또 다른 문제에 직면

  • 초기 핸드 쉐이크가 어떻게 든 네트워크의 요청으로 작동하고 오는하고 대답한다.

  • 그러나 MKCALENDAR 요청이오고 있습니다 (항목에 대한 캘린더 쿼리 또는 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는 자원 유형으로 calendar-collection을 가지고 있지만 mkcalendar를 시도합니까? 썬더 버드 번개와

: 달력-컬렉션

  • 초기 핸드 쉐이크는

  • 항목에 대한 PROPFIND 및 multiget 요청을하고있다 iCal의-항목에 대한 답변.

  • 그러나 그들은 표시되지 않고 오류 로그에 내가 나타납니다

  • 경고 : CalDAV를 : CalDAV를 : 실패를 가져 오기 오류 : 얻었다 상태 디버깅 프록시 달력 데이터를 가져 오는 (200), 제로

  • (독일어 텍스트 : 오류 코드 : 0X80004005) 디버그 프록시 : 경고 : 일정에 대한 오류 데이터를 읽는. 그러나이 오류 때문에 프로그램을 계속하려고 아마도 무시할 수있다. 오류 코드 : 0X80004005. 설명 : CalDAV를 : 오류 : 일정에 대한 오류 데이터를 읽는 : 경고 디버그 프록시 상태가 디버깅 프록시 (200 개) 일정 데이터, 제로

  • (: 오류 코드 READ_FAILED 독일어 텍스트)을 가져 오는 얻었다. 그러나이 오류 때문에 프로그램을 계속하려고 아마도 무시할 수있다. 오류 코드 : READ_FAILED. 설명 : - 그것은 어떤 인코딩 문제 일 수 있습니다 맥 OS 캘린더에서 작업하지만

  • HTTP 채널 수신기 OnDataAvailable 계약 위반

  • 비슷한 반응은?

어떤 힌트는 매우 감사합니다!

+0

DAV 서버를 개발하는 동안 SOP는 다음과 같이 보입니다. 1. 사양을 읽습니다. 2. 사양 해석에 해당하는 서버를 구현하십시오. 3. N 개의 실제 클라이언트로 테스트하여 N 개의 사양 해석을 제공합니다. 4. 희망을 포기하십시오. 5. 모든 것을 버리고 기존 구현을 복사하십시오. – CodeCaster

+0

모든 심각성은 제외 : 이것은 너무 광범위하고 답할 수 없습니다. 문제가 발생한 정확한 문제를 해결하기 위해 관련 정보가 충분하지 않습니다. 응답을 주셔서 감사합니다. – CodeCaster

+0

! 나는 당신이이 문제를 자세히 추적 할 수 없다는 것에 대해 분명하지만, 언급 한 나의 가정이 옳다면, 또는 이미 그 안에 몇 가지 결함이있다면 곧바로 발견 할 수 있습니다. –

답변

2

이 실제로 꽤 광범위한 질문이다. 그러나 내가 몇 가지 물건을 해결하기 위해 노력하자 : 당신을 위해, 당신은 정말 여기에 뭔가 들고 오지하려고해야 어렵다하더라도

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 ...

이 아마 bedeutet은 DASS는 적절한 구성 요소 유형 속성을 기본 일정 달력, 전혀 달력, 없음을 찾을 수 없습니다. 또는 수행 할 작업 (미리 알림 앱 동일한 계정)에 대한 모든 동일. MKCALENDAR의 페이로드는 무엇입니까? 당신이 그것을 알아낼 수없는 경우/자세한 내용은 O를, 포함 된 모든 관련 세부 사항 (당신이 집 쿼리에 대한 응답으로 보내 예를 들어, XML)와이에 특정 질문을 승 하드 진단합니다.

Thunderbird Lightning

아마 버전에 많이 의존하고 당신이 사용하고있는 확장이에 대해 많은 말을 할 수 없습니다. AFAIK 많은 사람들이 썬더 버드와 함께 적절한 칼/CardDAV를를 얻기 위해 ScalableOGo 썬더 버드 확장을 사용합니다.

+0

응답에 대한 많은 감사 !!! –

+0

sync-collection : 이해합니다. 더 자세히 조사하려고합니다. basic-sync : 요청에 응답의 데이터/항목이 포함되어 있지만 항목 데이터의 깊이 = 1 인 propfind가 있습니다. 보내다. 어쩌면 그게 정확하게 두 가지 방법으로 시도하는 문제 (calendar query + propfind) 나는 현재 dav : 1, calendar-access 및 allow로만 응답합니다. OPTIONS, PROPFIND, HEAD, GET, REPORT ios-Cal : 위의 붙여 넣은 mkcalendar의 페이로드 썬더 버드 : 감사합니다 다른 확장을 시도합니다 !!! ;-) –

+0

정말 페이로드를 포함해야합니다 ... (예 : 요점을 사용 하시겠습니까?) 명확하고 명확한 질문을하십시오. 이 질문을 더 크게 만드는 것은 의미가 없습니다. 개별 질문에 개별 문제를 해결하십시오. – hnh

1

Thunderbird/Lightning의 경우 고급 구성 편집기에서 calendar.debug.logcalendar.debug.log.verbose을 켜고 다시 시작할 수 있습니다. Options > Advanced > General > Config Editor에서 찾을 수 있습니다. 이렇게하면 더 자세한 http 요청과 실패한 정보를 얻을 수 있습니다. remote debugger을 연결하고 네트워크 모니터를 보거나 the code에 중단 점을 설정할 수도 있습니다.

썬더 버드/라이트닝에서는 webdav-sync 초안의 이전 버전과 현재 버전을 혼합하여 사용하고 있습니다. 나는 그것이 매우 일반적이라는 점을 감안할 때, 오류 메시지로부터 많이 말할 수는 없지만 결과에 예기치 않은 것이있는 것처럼 보입니다.

기존 서버 (예 : sabre/dav)와 클라이언트 간의 핸드 쉐이크를 비교 한 다음 커뮤니케이션과 차이점을 확인하십시오.

또한 Apple의 서버 상호 운용성을 확인하는 CalDAVTester에 관심이있을 수 있습니다. 그러나 사과에 대한 다양한 테스트가 포함되어 있습니다. CalConnect의 사람들은 Apple과 함께 더 일반적으로 사용 가능하고 Apple 전용 테스트를 분리하려고 노력하고 있습니다. 서버가 읽기 전용이므로 모든 것이 제대로 작동 할 것이라고 기대하지는 말고 특정 테스트를 수정하십시오.

+1

Philipp : webdav-sync * draft *의 '이전'버전과 '현재'버전을 사용하지 마십시오. [RFC 6578] (https://tools.ietf.org/html/rfc6578)을 사용하십시오. 2012 년 3 월부터입니다! :-) – hnh

+0

나는 이미 달력을위한 썬더 버드 로그를 가능하게했다. 나는 또한 caldavtester를 다운로드했지만 파이썬 스크립트의 설정으로는 지금까지 실패했다. 일부 온라인 테스터에 따르면 유효성이있는 것으로 보일지라도 여전히 인코딩이있는 것으로 가정하십시오. 더 조사 할 것이고 또 다시 물어볼 것입니다. ;) –

+0

@hnh 나는 이상적인 세상에서 webdav-sync의 이전 초안에 대한 지원을 중단하는 것이 좋을 것이라는 데 동의하지만, 클라이언트와 마찬가지로 RFC와는 잘 작동하지 않으며 이전 버전을 필요로하는 서버가 있습니다. 초안. 우리가 지금 가지고있는 하이브리드 접근법은 구형 서버와 새 서버 모두에서 상당히 잘 작동합니다. 그렇지 않은 경우 버그를 신고하십시오. –