I’m happy that people are participating. However, it makes me nervous if there are too many open issues and for this one, I can’t do anything because there is no known incompatibility from DAVdroid’s side. So, I’ll close this. If you find any DAVdroid problems in relation to Tine, please either create a new issue or post here if the issue is only valid for Tine.
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.