[caldeveloper-l] sync-tokens vs PROPFIND
David Given
dtrg at google.com
Mon Nov 13 02:14:29 PST 2017
I'm involved with CalDAV rather than CardDAV, which is a different team and
a different technology stack, but I'm well aware that this is not really an
important difference from the outside... that definitely looks like a bug;
I will escalate it to the appropriate people.
(Incidentally, if anyone observes any other similar oddities, please get in
touch.)
On Mon, 13 Nov 2017 at 09:10 Bron Gondwana <brong at fastmailteam.com> wrote:
> Hi David,
>
> I know this is contacts rather than calendars, but here's a perspective
> from the other side about why people don't support optional/extended
> standards in their clients:
>
> <<<<<<<< REPORT
> https://www.googleapis.com:443/carddav/v1/principals/brongondwana%40gmail.com/lists/default/
> HTTP/1.1
> <D:sync-collection xmlns:C='urn:ietf:params:xml:ns:carddav' xmlns:CY='
> http://cyrusimap.org/ns/'
> xmlns:D='DAV:'><D:sync-token/><D:sync-level>1</D:sync-level><D:prop><D:getetag/></D:prop></D:sync-collection>
> >>>>>>>> HTTP/1.1 400 Bad Request
> <?xml version="1.0" encoding="UTF-8"?>
> <d:error xmlns:d="DAV:"/>
>
> Of course this is carddav rather than caldav, but if you're building a
> general client library, you quickly wind up chasing the lowest common
> denominator rather than writing two different codepaths, one for
> modern/correct servers and one for old servers that only support the base
> standard or have buggy newer behaviour.
>
> Particularly when docs lie:
>
> https://developers.google.com/google-apps/carddav/
>
> Here's what I got back from a PROPFIND:
>
> <d:response>
> <d:href>/carddav/v1/principals/brongondwana at gmail.com
> /lists/default/</d:href>
> <d:propstat>
> <d:status>HTTP/1.1 200 OK</d:status>
> <d:prop>
> <d:displayname>Address Book</d:displayname>
> <d:current-user-privilege-set>
> <d:privilege>
> <d:read/>
> </d:privilege>
> <d:privilege>
> <d:read-acl/>
> </d:privilege>
> <d:privilege>
> <d:read-current-user-privilege-set/>
> </d:privilege>
> <d:privilege>
> <d:unlock/>
> </d:privilege>
> <d:privilege>
> <d:write/>
> </d:privilege>
> <d:privilege>
> <d:write-acl/>
> </d:privilege>
> </d:current-user-privilege-set>
> <d:supported-report-set>
> <d:supported-report>
> <d:report>
> <d:principal-search-property-set/>
> </d:report>
> </d:supported-report>
> <d:supported-report>
> <d:report>
> <card:addressbook-query/>
> </d:report>
> </d:supported-report>
> <d:supported-report>
> <d:report>
> <d:expand-property/>
> </d:report>
> </d:supported-report>
> <d:supported-report>
> <d:report>
> <d:principal-property-search/>
> </d:report>
> </d:supported-report>
> <d:supported-report>
> <d:report>
> <d:acl-principal-prop-set/>
> </d:report>
> </d:supported-report>
> <d:supported-report>
> <d:report>
> <card:addressbook-multiget/>
> </d:report>
> </d:supported-report>
> <d:supported-report>
> <d:report>
> <d:principal-match/>
> </d:report>
> </d:supported-report>
> <d:supported-report>
> <d:report>
> <d:sync-collection/>
> </d:report>
> </d:supported-report>
> </d:supported-report-set>
> <d:resourcetype>
> <d:collection/>
> <card:addressbook/>
> </d:resourcetype>
> </d:prop>
> </d:propstat>
> <d:propstat>
> <d:status>HTTP/1.1 404 Not Found</d:status>
> <d:prop>
> <d:acl/>
> <d:sync-token/>
> </d:prop>
> </d:propstat>
> </d:response>
> </d:multistatus>
>
> RFC6578 is pretty clear:
>
> 3.2. DAV:sync-collection Report
>
> If the DAV:sync-collection report is implemented by a WebDAV server,
> then the server MUST list the report in the
> "DAV:supported-report-set" property on any collection that supports
> synchronization.
>
>
> The server claims to support sync-collection, but it actually doesn't.
>
> It doesn't take dealing with many bogus servers like this and you just
> give up on the more efficient method.
>
> Do you have any contacts in the contacts team you could pass this on to?
> I guess I'll make my code check for sync-token existing as well as for the
> standard supported-report-set.
>
> Cheers,
>
> Bron.
>
> On Wed, 8 Nov 2017, at 03:38, David Given wrote:
>
> Hello everybody,
>
> I have an RFC question I'd appreciate some feedback on...
>
> We have a situation where a Calendar client is trying to get the etags of
> every event in an enormous calendar in a single query. Naturally, this
> isn't working.
>
> They're doing this:
>
> PROPFIND /caldav/v2/$USERNAME/events
> <?xml version="1.0" encoding="UTF-8"?>
> <A:propfind xmlns:A="DAV:">
> <A:prop>
> <A:getcontenttype/>
> <A:getetag/>
> </A:prop>
> </A:propfind>
>
> As you can see, they're not asking for a sync token.
>
> RFC6578 section 3.6 provides a mechanism where clients can ask for
> paginated responses, where the server returns partial data with a 507
> status code, and a new sync token so they can continue the query. It is a,
> however, a bit ambiguous as to whether this is supported for methods other
> than REPORT. The interwebs suggest it is (but I'd appreciate a
> clarification here).
>
> My question is. however:
>
> Is it permissable to return a sync-token (and expect the client to honour
> it) *even if the client's original query didn't ask for it*?
>
> I'm hoping the answer is going to be yes, but if it's no --- any
> suggestions?
>
> Thanks!
>
> David Given
> dtrg at google.com
>
> *_______________________________________________*
> caldeveloper-l mailing list
> caldeveloper-l at lists.calconnect.org
> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org
>
>
> --
> Bron Gondwana, CEO, FastMail Pty Ltd
> brong at fastmailteam.com
>
>
> _______________________________________________
> caldeveloper-l mailing list
> caldeveloper-l at lists.calconnect.org
> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20171113/9252f778/attachment-0001.html>
More information about the caldeveloper-l
mailing list