0

While doing initial sync with Google's CardDav server I am doing a REPORT request with sync-collection method. In this request I am passing empty sync-token since its the initial sync. This is as per RFC 6578 (https://www.rfc-editor.org/rfc/rfc6578#section-3.8).

The request body looks like this:

<?xml version="1.0" ?>
<D:sync-collection xmlns:D="DAV:">
<D:sync-token/>
<D:prop>
    <D:getetag/>
</D:prop>
</D:sync-collection>

I am expecting a Multi-Status response with etag's of all contacts. However, google is returning HTTP error 400.

Can anybody if I am doing anything wrong?

Community
  • 1
  • 1
anas17in
  • 161
  • 9
  • Does Google CardDAV support the sync collection REPORT? – hnh Oct 19 '17 at 04:57
  • Yes, as per this doc [Google Carddav API](https://developers.google.com/google-apps/carddav/), it does. – anas17in Oct 19 '17 at 05:11
  • OK. What URL do you hit? Also the page is a little weird, they say “after the first sync”, so maybe they do not support reports w/o a token. – hnh Oct 19 '17 at 05:18
  • I am hitting this URL: https://www.googleapis.com/carddav/v1/principals/userEmail/lists/default – anas17in Oct 19 '17 at 05:21

1 Answers1

0

Your request is missing the sync-level element as per https://www.rfc-editor.org/rfc/rfc6578#section-6.1

   <!ELEMENT sync-collection (sync-token, sync-level, limit?, prop)>

The Google API is not totally clear about whether they do support empty sync token.

Client applications must switch to this mode of operation after the initial sync.

and

Client programs use the sync-token PROPFIND request on the Address Book to obtain the sync-token representing its current state. Client applications must store this value and issue periodic sync-collection REPORT requests to determine changes since the last issued sync-token. Issued tokens are valid for 29 days, and the REPORT response will contain a new sync-token.

so it is well possible that they rejected the request for that reason. If it is the case, one would do a PROPFIND with Depth:1 asking for the sync-token property as well as the getetag, then do a sync request based on the sync token property retrieved.

Community
  • 1
  • 1
Arnaud Quillaud
  • 4,420
  • 1
  • 12
  • 8
  • It does not make a difference by adding `1` to the request. However, I think you are correct w.r.t. using PROPFIND for initial sync to get etags and sync-token. But this is weird since empty sync-token approach works with both iCloud and Fastmail. – anas17in Oct 19 '17 at 08:40
  • Well, as they say: "We have not implemented the full specification". And they mean it ;-/ – hnh Oct 19 '17 at 09:51