[buteo-sync-plugin-caldav] Retrieve full event after PUT when the etag is missing.
As discussed in nemo-qml-plugin-calendar!59 (merged), my CalDAV provider is now using the SEQUENCE part of event on PUT, checking that proposed SEQUENCE is greater or equal to the value on server. For recurring events, a modification to an exception is internally increasing the SEQUENCE on server. Here is an example:
- a recurring event A with SEQUENCE:1 and sync,
- create an exception on device will create event A-1 with SEQUENCE:1 and sync,
- a GET on series A from server will reveal that A-1 sequence is 1, but A sequence itself is now 2, because the server internally raiused it.
- obviously on device, the sequence for A is still 1. Adding a new exception will then fail to upsync because the sent sequence is lower than the value on server.
I thought of a bug of my provider, and open a ticket there with the above example. The answer was clear and detailled. Since the server is not sending etag value after the PUT, a GET is mandatory to get the exact content on server. Currently in the client we were just retrieving the etag in a separate GET. But this is error prone since the event may have changed on server between the PUT and the GET...
Here is a copy of the answer:
Clients should not rely that the calendar resource was stored on the server literally as being sent, when no ETag is included in the response. E.g. certain metadata of the event such as timestamps do change implicitly along with each update operation, so that the actual iCalendar representation will likely never be the same as in the PUT request. Therefore, clients usually re-get the resource after PUT operations automatically on their own (either by performing a DAV:sync-collection REPORT-, or an explicit GET-request directly afterwards.
To mitigate the verbosity, the "Prefer" header field with the "return=representation" preference would allow to include the updated calendar object resource directly in the response body (as specified in RFC 8144). However, our server does not yes support all parts of this specification, so that still the additional roundtrip to reload the updated resource is necessary at the moment.
As for the internal sequence number handling - for series events with overridden instances, incoming updates are processed sequentially, so that there may be situations where the sequence number is incremented more than one time when applying all updates of the calendar object resource. However, I've never seen that this would be a problem for clients - as outlined above, I'd recommend to retrieve the resource from the server after updates to ensure the same revisions is knwon to the client.
I'm thus modifying the sync code to add a full event GET after a PUT when the etag is not in the response headers. From my tests, this is completely curing my upsync issues to an Open-Xchange server.