2014-12-22 84 views
0

我試圖不重新發明這裏的車輪...Davical同步令牌Web請求

我發現在CalDAV同步實施了一些不錯的文檔there

根據其網站,DaviCal是rfc6578自0.9.8版起(見here)。

如下因此,我先把我的請求得到了同步令牌:

PROPFIND http://my_cal_srv/user/calendar_path HTTP/1.1 
Content-Type: application/xml; charset="utf-8" 
    <?xml version="1.0" encoding="utf-8" ?> 
     <d:propfind xmlns:d='DAV:'> 
     <d:prop> 
      <d:displayname /> 
      <d:sync-token /> 
     </d:prop> 
     </d:propfind> 

這將返回預期的數據:

<?xml version="1.0" encoding="utf-8" ?> 
<multistatus xmlns="DAV:"> 
<response> 
    <href>/caldav.php/user/calendar_path/</href> 
    <propstat> 
    <prop> 
    <displayname>My Calendar</displayname> 
    <sync-token>data:,9</sync-token> 
    </prop> 
    <status>HTTP/1.1 200 OK</status> 
    </propstat> 
</response> 
</multistatus> 

到目前爲止好,我有一個令牌,它的「數據:,9「。所以,讓我們嘗試從8開始獲取更改,這是我在添加事件之前查詢服務器時獲得的令牌。

REPORT http://my_cal_srv/user/calendar_path HTTP/1.1 
Content-Type: application/xml; charset="utf-8" 
<?xml version="1.0" encoding="utf-8" ?> 
<d:sync-collection xmlns:d="DAV:"> 
    <d:sync-token>8</d:sync-token> 
    <d:sync-level>1</d:sync-level> 
    <d:prop> 
    <d:getetag/> 
    </d:prop> 
</d:sync-collection> 

答案是:

<?xml version="1.0" encoding="utf-8" ?> 
<multistatus xmlns="DAV:"> 
<response> 
    <href>/caldav.php/user/path/86166f9c-3e2e-4242-9a28-0f3bfb1dd67a-caldavsyncadapter.ics</href> 
    <propstat> 
    <prop> 
    <getetag>"5ed2101b0c867e490dbd71d40c7071bb"</getetag> 
    </prop> 
    <status>HTTP/1.1 200 OK</status> 
    </propstat> 
</response> 
<response> 
    <href>/caldav.php/user/path/cb354fab-b41d-49ad-8a4f-8d68c9090ea0.ics</href> 
    <propstat> 
    <prop> 
    <getetag>"334892703f4151024e9232eab9b515a7"</getetag> 
    </prop> 
    <status>HTTP/1.1 200 OK</status> 
    </propstat> 
</response> 
<sync-token>data:,9</sync-token> 
</multistatus> 

刪除條目後(所以我得到同步令牌10,仍然比較使用令牌8),我得到以下結果:

<?xml version="1.0" encoding="utf-8" ?> 
<multistatus xmlns="DAV:"> 
<response> 
    <href>/caldav.php/user/cal_path/86166f9c-3e2e-4242-9a28-0f3bfb1dd67a-caldavsyncadapter.ics</href> 
    <status>HTTP/1.1 404 Not Found</status> 
</response> 
<response> 
    <href>/caldav.php/user/cal_path/cb354fab-b41d-49ad-8a4f-8d68c9090ea0.ics</href> 
    <propstat> 
    <prop> 
    <getetag>"334892703f4151024e9232eab9b515a7"</getetag> 
    </prop> 
    <status>HTTP/1.1 200 OK</status> 
    </propstat> 
</response> 
<sync-token>data:,10</sync-token> 
</multistatus> 

所以我有點困惑,因爲我真的不知道如何解釋這些結果...

有人可以請exp讓我知道如何從這裏提取同步信息?這是有點難以弄清楚的變化類型,因爲ICS的名稱不清楚...

在此先感謝幫助...和快活的X - 馬斯! Regards, N.

回答

1

你得到一個「data:,9」並不意味着你實際上可以查詢「data:,8」或者7等。同步令牌是不透明的,不會給你一個版本控制系統(你需要像DAV Versioning Extensions那樣的)。

DAV sync-tokens是一種簡單的優化技術 - 僅此而已。它們對客戶端來說是完全不透明的,並且服務器可以隨時過期同步令牌(並且不需要保存墓碑等)。例如,無法存儲墓碑的服務器可以簡單地在DELETE請求上過期令牌。

您使用同步令牌的方法是:

  1. 找出哪些需要重新同步
  2. 一個孩子集合
  3. 內優化資源的同步父集合的子集

1)子集合需要被同步

假設你有日曆的集合(如my_cal_srv /用戶/),你做一個PROPFIND深度:1在這個集合上,請求子集合的同步標記。如果這些與客戶端的緩存不匹配,則需要對這些子集合進行同步。

注意:不要使用你從這個請求中得到的令牌來同步子集合(這是你在上面做的)。它可能已經過期。在同步報告中,只使用來自同步報告的令牌!

2)優化的收集內容

同步還是那句話:同步令牌是一種優化,僅此而已。您始終需要做好準備以獲取(有效)同步令牌前提條件錯誤(這意味着服務器已過期令牌)並完全重新獲取收集內容!然後將這個(URL,ETag)與你的緩存版本進行比較,找出更改的內容。 (基本上當你有一臺服務器不支持同步報告時,你需要做的所有步驟)。

如果您在同步報告結果中收到同步令牌,則可以在下一個同步請求中使用它。如果服務器仍然有狀態,它只會給你更改。如果它過期了令牌,它會給你同步令牌錯誤。

注意:如果不明顯 - 在第一次同步請求中,您不(不能)提供令牌。您運行不帶令牌的查詢並獲取所有內容。如果服務器向您發送(in)有效同步令牌錯誤,則再次執行同樣的操作。

+0

這裏所有的作品都很好。 請注意,對於** DaviCal **,看起來如果令牌已過期,服務器會自動在請求中返回** ALL **事件。我用任意一個隨機密鑰測試了請求,並且我從來沒有收到錯誤響應,但是查看內容時,它總是返回位於服務器上的所有事件。 – neggenbe

+0

DaviCal中的主要錯誤。當一個令牌過期時,客戶如何找出哪些資源被刪除?對於客戶端來說,它看起來像令牌很好,並將結果作爲變更集處理(沒有指示響應包含所有內容)。 – hnh

+0

好點 - 關於如何應對這個問題的任何建議? – neggenbe

1

您沒有做出正確的請求。在你的要求,你必須:

<d:sync-token>8</d:sync-token> 

但這應該是:

<d:sync-token>data:,8</d:sync-token> 

除此之外,你所得到的第一反應告訴你:

These resources have been changed or newly created: 
/caldav.php/user/path/86166f9c-3e2e-4242-9a28-0f3bfb1dd67a-caldavsyncadapter.ics 
/caldav.php/user/path/cb354fab-b41d-49ad-8a4f-8d68c9090ea0.ics 

第二反應告訴你:

This resource has been changed or newly created: 
/caldav.php/user/cal_path/cb354fab-b41d-49ad-8a4f-8d68c9090ea0.ics 

This resource has been deleted: 
/caldav.php/user/cal_path/86166f9c-3e2e-4242-9a28-0f3bfb1dd67a-caldavsyncadapter.ics 
+0

好的,重新挖掘它。因此,這意味着狀態變量是一個尋找: 對於添加/更新的條目我去拿狀態200 HTTP/1.1 200 OK 對於刪除的條目我去拿狀態400 HTTP/1.1 404沒有找到 這是你如何解釋結果? – neggenbe

+0

是的,非常。這一切都在規範中。 – Evert