Search code examples
httpwebrequestsynchronizationwebdavcaldav

Davical Sync-Token web request

I am trying not to re-invent the wheel here...

I have found some nice documentation on CalDav sync implementation there

According to its website, DaviCal is rfc6578-compliant since v. 0.9.8 (see here).

I therefore first send my request to get the sync token as follows:

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>

This returns data as expected:

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

So far so good, I have a token, it's "data: ,9". So, let's just try to get changes since 8, the token I had when I queried the server prior to adding some event.

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>

The answer is:

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

After deleting an entry (so I get sync-token 10, and still compare using token 8), I get following result :

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

So I am a little confused here as I don't really know how to interpret these results...

Could anybody please explain to me how to extract the sync info from here? It is a little hard to figure out the changes types because the ICS namings are unclear...

Thanks in advance for helping out... And merry X-Mas ! Regards, N.

Solution

  • That you get a "data:,9" doesn't imply you can actually query "data:,8" or ,7 etc. Sync tokens are opaque and do NOT give you a versioning system (you need sth like DAV Versioning Extensions for that).

    DAV sync-tokens are a simple optimization technique - nothing more. They are completely opaque to the client and the server can expire sync tokens at any time (and is not required to save tombstones and such). Eg a server which can't store tombstones can simply expire tokens on DELETE requests.

    The way you use sync-tokens is:

    1. to figure out which child collections of a parent collection need to be re-synced
    2. to optimize syncing of a the resources within a child collection

    1) Which child collections need to be synced

    Assume you have a collection of calendars (e.g. my_cal_srv/user/) and you do a PROPFIND Depth:1 on this collection, asking for the sync-tokens of the child collections. If those don't match the ones of your clients cache anymore, you know you need to perform a sync of just those child collections.

    Note: do NOT use the token you got back from this request to sync the child collection (which is what you do above). It might have expired already. Within sync-reports only use tokens you got from sync-reports!

    2) Optimizing syncing of the collection contents

    Again: sync-token's are an optimization, nothing more. You always need to be prepared to get an (in)valid-sync-token precondition error (which means the server expired the token) and do a full refetch of the collection contents! And then compare that (URL,ETag) to your cached version to figure out what the changes are. (essentially all the steps you need to do when you have a server which doesn't support sync-reports).

    If you get a sync-token in the sync-report results, you can then use it in the next sync-request. If the server still has the state, it'll just give you the changes. If it expired the token, it'll give you the sync-token error.

    Note: In case it isn't obvious - in the very first sync-request you don't (can't) provide a token. You run the query w/o a token and get back all the contents. You do the same again if the server sends you an (in)valid-sync-token error.