Split caldav PROPFIND response when it is too large

Question

I have home-grown CalDAV implementation which normally works fine, but with one problem. There are clients with hundreds calendars which are synchronized over mobile network. Each time iCalendar ask PROPFIND with depth=1 my server must answer with full list of calendars giving huge response which fails sometimes because of unstable mobile network.

I guess splitting response in smaller chunks (like 30 per response) would help but i don't know if it really possible.

So question is - Can i force client to PROPFIND calendars in consecutive requests by chunks of N calendars?

Answer 1

No, there's no agreed-upon standard for this.

That being said: (1) are you compression the response? (2) have you looked at https://datatracker.ietf.org/doc/html/draft-murchison-webdav-prefer-05?

Answer 2

When you say "100's of calendars" do you mean "100's of events"? Because a PROPFIND response with 100's of items actually isnt big, thats perfectly normal. But quite often the list of events in a calendar can be large. But Apple usually do quite good caldav clients, and they should be doing REPORT requests with appropriate date range so they dont get too many events.

Its possible that your Caldav server doesnt implement the full range of reports so the client is falling back to a simpler approach.

Answer 3

As mentioned by brad, you need to differentiate between numbers of calendars and numbers of events within a calendar.

Having hundreds of calendars is very unusual, but just that should be kinda OK. A PROPFIND with 100 results isn't too big. Also note the CTag, if that's available you know whether you need to sync the calendar contents in the first place.

Most likely you are actually asking about some calendars containing a lot of events, could be thousands. In such cases the PROPFIND:1 on the calendar to grab the ETags to check for changes can become large&slow. (in any case make sure you do support Accept-Encoding: gzip and Brief:T).

For this case there is an RFC'd solution: RFC 6578. With sync-reports you only need to return the records which changed since the last sync. It's supported by iOS and iCal. The spec also supports batching (called truncation in the RFC), but this isn't implemented in all clients.