It’s not necessary, but the Android Calendar app fills the ORGANIZER field of an event with the account’s name. DAVdroid writes “mailto:” + the ORGANIZER field to the ORGANIZER property. So if you use ORGANIZER and attendees, make sure you use the organizer email address as account name. It may also be that you can’t edit events when the ORGANIZER differs.
mailbox.org 102 Processing
-
Here’s the debug info:
(CalDAV source has three calendars, 26 is the main one, happened right after re-creating the combined Cal and CardDAV account on the Android)
Edit: DAVdroid doesn’t sync any of the calendars
-
Thanks for the report. It seems like
dav.mailbox.orgexpects that processing of the multi-get request will take longer than 20 seconds (which is strange because sending a few events shouldn’t take that long). Thus, it sends the (very rarely used) WebDAV interim HTTP status code 102 Processing, which is defined in RFC 2518 (WebDAV).- okhttp and thus dav4android/DAVdroid don’t support this HTTP status code (yet). It’s also the first time that I have ever seen it in real.
- In the latest WebDAV standard (RFC 4918), status code 102 has been dropped (probably because 100 does well). So, I don’t know whether it makes much sense to implement this status code, when it’s not there anymore in the latest WebDAV version.
I will consider how to handle that.
Does your calendar have a lot of entries?
-
I have now
- created an okhttp issue for discussing 102 Processing support,
- written to OpenXChange (the software behind mailbox.org) to suggest using the more widely supported status code 100 Continue instead of 102 Processing.
-
@rfc2822 said:
- okhttp and thus dav4android/DAVdroid don’t support this HTTP status code (yet). It’s also the first time that I have ever seen it in real.
Looks like my black thumb triggered…
Does your calendar have a lot of entries?
Kinda, yep. But syncing the main calendar only worked fine.
Might I suggest having a preference like “only sync/fetch old calendar entries for (x) a month (x) 3 months back in time”? If this even is defined in the corresponding RFCs, this might help here and save sync-time. -
@vautee said:
Might I suggest having a preference like “only sync/fetch old calendar entries for (x) a month (x) 3 months back in time”? If this even is defined in the corresponding RFCs, this might help here and save sync-time.
We’re planning to implement this, but it will take time.
Another thing… maybe the circumstances which lead to the 102 Processing headers are temporary. Did you try again later again? Otherwise, I can only suggest to use smaller calendars as a workaround (if that helps), until the real problem is solved.
-
@rfc2822 said:
Another thing… maybe the circumstances which lead to the 102 Processing headers are temporary. Did you try again later again? Otherwise, I can only suggest to use smaller calendars as a workaround (if that helps), until the real problem is solved.
I already tried re-syncing yesterday… now it went fine a minute ago \o/ Let’s see what happens on the next iteration. And yes, I’ll have a look if I can remove some years of old calendar entries.