Open j-dimension opened 2 years ago
Ein Request so wie ihn DAVx5 ausführt:
2021-10-15 00:17:25 102581 [HttpClient] --> PUT https://cloud./remote.php/dav/calendars/jens/jens/Nextcloud-IWIEEL0GZK8L0QM1DYP8PM.ics http/1.1
2021-10-15 00:17:25 102581 [HttpClient] If-Match: "e01101434298685bb1452dcf5353de32"
2021-10-15 00:17:25 102581 [HttpClient] User-Agent: DAVx5/4.0-gplay (2021/10/10; dav4jvm; okhttp/4.9.1) Android/11
2021-10-15 00:17:25 102581 [HttpClient] Accept-Language: de-DE, de;q=0.7, *;q=0.5
2021-10-15 00:17:25 102581 [HttpClient] Content-Type: text/calendar;charset=utf-8
2021-10-15 00:17:25 102581 [HttpClient] Content-Length: 773
2021-10-15 00:17:25 102581 [HttpClient] Host: cloud.
2021-10-15 00:17:25 102581 [HttpClient] Connection: Keep-Alive
2021-10-15 00:17:25 102581 [HttpClient] Accept-Encoding: gzip
2021-10-15 00:17:25 102581 [HttpClient] Cookie: cookie_test=test; ocwmg5f6kn3t=nssd3onld2jktai14idbil9on0; __Host-nc_sameSiteCookielax=true; __Host-nc_sameSiteCookiestrict=true; oc_sessionPassphrase=E8dbG%2FiKG6waldlHZ%2FWJT%2FK3ZU71LotOvfJG73Gd3nDCWT8d%2BfPg8%2FVYGVdPUe0TI1iWLx6HgR55MkKyf%2FO2v1Bsvi9Ai8C%2FFl1UdA34tujcHvDOjus1Y9KFDIZSagvk
2021-10-15 00:17:25 102581 [HttpClient]
2021-10-15 00:17:25 102581 [HttpClient] BEGIN:VCALENDAR
VERSION:2.0
PRODID:DAVx5/4.0-gplay ical4j/3.1.0 (org.withouthat.acalendar)
BEGIN:VEVENT
DTSTAMP:20211014T221725Z
UID:B3U1MXES0AKNXNUH8W1CG
SEQUENCE:24
SUMMARY:bla bla
DTSTART;TZID=Europe/Berlin:20211015T103000
DTEND;TZID=Europe/Berlin:20211015T120000
CLASS:PUBLIC
STATUS:CONFIRMED
CREATED:20200114T153355Z
X-MOZ-GENERATION:2
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/Berlin
LAST-MODIFIED:20201010T011803Z
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
END:VCALENDAR
2021-10-15 00:17:25 102581 [HttpClient] --> END PUT (773-byte body)
I noticed that the external application does not send the ETag of the event in an If-Match header. Nextcloud still updates the event, but could that cause the sync on the iPhone to behave weird and duplicate the event (just in its local calendar)?
I think this might indeed be down to the ETag - if there's none set then the CalDAV server assumes it's a new event. Is this still an issue for you?
Nextcloud version (eg, 20.0.5): 20.0.4 Operating system and version (eg, Ubuntu 20.04): Ubuntu 20.04
The issue you are facing:
I have an issue with the iOS (iPhone) calendar duplicating all events once they are updated.
So, calendar setup works fine and it syncs successfully. Then, another client updates an event, the update is correctly processed by Nextcloud and I see only ONE updated event in the web UI. But when the iPhone picks up the changes, it duplicates the event. There is one duplicate for each update the event received.
The external client is just issuing HTTP PUT on the event resource, e.g. with a payload like this:
Is this the first time you’ve seen this error? (Y/N): Y
Steps to replicate it:
Under which circumstance would the iPhone CalDAV client duplicate the event?
Thanks, Jens