mailbox.org 102 Processing

DAVx⁵
Log in to reply
  • ?

    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)

    http://pastebin.com/z0MzwZA7

    Edit: DAVdroid doesn’t sync any of the calendars

    0
  • rfc2822
    developer

    Thanks for the report. It seems like

    1. dav.mailbox.org expects 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).
    2. 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.
    3. 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?

    ? 1 Reply 0
  • rfc2822
    developer

    I have now

    0
  • ?

    @rfc2822 said:

    1. 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.

    rfc2822 1 Reply 0
  • rfc2822
    developer

    @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.

    ? 1 Reply 0
  • ?

    @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.

    0

Similar topics