[caldeveloper-l] sync-tokens vs PROPFIND

[Ken Murchison]

My guess is that if the client is blindly requesting the ETag of every 
resource using a PROPFIND rather than a sync-collection REPORT, that the 
client will have no clue what a sync-token is if you return it

I'd push back on the client developer and educate them that 
sync-collection is almost mandatory to implement for any well-behaved 
CalDAV/CardDAV client.

Is the PROPFIND not working because Google can't handle it or the client 
times out waiting for the response?  If the latter, we at Fastmail 
recently experienced the same thing with requests that require a huge 
response to be generated.  We fixed this by updating the Cyrus IMAP 
server so that responses to PROPFIND and REPORT get "streamed" to client 
using chunked transfer-encoding. This keeps the client from timing out.


On 11/07/2017 11:38 AM, 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 <mailto:dtrg at google.com>
>
>
>
> _______________________________________________
> caldeveloper-l mailing list
> caldeveloper-l at lists.calconnect.org
> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org

-- 
Ken Murchison
Cyrus Development Team
FastMail Pty Ltd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20171107/16bd4070/attachment.html>