@nate2014jatc Maybe you could ask in the Nextcloud forum. As far as I know, issues are better for reporting bugs than asking questions, and it will take longer to get an answer.

@heX16 That would certainly be possible, if there is no other solution (like fixing the problem where it comes from). I’d really appriciate if you could contact the MyPhoneExplorers and tell me what they say? Android account names can easily contain Unicode characters, for instance if you use local language. What if you name an account “Mein schöner Account”? Or “мой аккаунт”? Such names should work with any app, and they’re not related to DAVx⁵.

@wanderlei-huttel I see, sorry… didn’t notice the logs. It doesn’t look suspicious from DAVx⁵ point of view.

@mtausig Ok. Please contact the service which generated the .ics file to fix that.

@xuziq2000 I see… Seems like it also works without OAuth2, because DAVx⁵ doesn’t support OAuth. However your problem seems to be a server problem. Is there is anything specific we can do for you, just let us know.

OK, got a reply, the feed is now fixed, thanks a lot for the help!

@rfc2822 I’m sorry, I can’t. But my fantatstic admin was able to! All is back to normal now, thanks for assistance.

@sergio Workaround still works (using DAVx⁵ 2.2.1-ose and OpenTasks 1.1.15), however, once I check a task as done in OpenTasks the issue returns with the next sync. Now I’m using aCalendar+ as calendar app and OpenTasks to sync tasks. When I get a notification for a due task, I just check it as done in the aCalendar+ notification. Notifications from OpenTasks are deactivated. A sync thereafter does not trigger Vibration. So the Vibration only happens after checking within the OpenTasks notification.

I’ve been able to figure out why the import in Thunderbird failed for the 51 entries: If the UID of a VEVENT contains “@domainname.tld” or “@machine-name”, the Posteo.de CalDAV server returns HTTP statuscode 404 for the REPORT HTTP method. I have now removed all occurences of “@followedbyastring” and successfully imported my .ics-file with Thunderbird. I have not tested the import on my phone using DAVdroid and Calendar Import Export. Should Posteo.de support occurences of “@followedbyastring” in a UID? If I have time to do so, I will report this issue to Posteo.de But please: Feel free to test and report the issue to Posteo.de Sorry for the noise, I initially thought this was a DAVdroid problem.

Thanks for the logs. I was finally able to reproduce a similar situation: Upload an event with UID:a%40b (note the %, for instance coming from some erroneously double-encoded old UID; nevertheless valid) to Google /events/a%40b.ics (or anything else) Google usually rewrites the path (= moves the event) to <UID>.ics, which would be a%40b.ics. However, Google CalDAV REPORT calendar-query reports /events/a%2540b.ics as the URL of the resource. If you want to download /events/a%2540b.ics from Google, it returns 404, although it had just listed this path. So, in my opinion and what I currently know about it, this seems to be a server problem. It should go away if you delete all events on the server and then only create/sync “clean” events with “good UIDs”. Maybe you can also create a new calendar for testing and see whether this one works?

Ok, then you very much for your fast help! I’ll look into the server logs again. Is there a way to close this Thread?

For reference and transparency: We have created this report on Apple Bug Reporter on 17 Oct 2015 here: https://bugreport.apple.com/web/?problemID=23156564 Summary: When querying resource properties with PROPFIND, iCloud returns the same property (in this example: <resourcetype/>) one time as 200 OK and one time as 404 Not Found. This doesn’t make any sense and causes clients to ignore the property and thus to fail. Steps to Reproduce: curl --data @1.xml -vX PROPFIND -H 'Depth: 1' -u xxxxxx:XXXXXX https://p23-caldav.icloud.com/xxxxxxxx/calendars/ Expected Results: Don't send <resourcetype/> with propstat status 404. Actual Results: The response for <href>/xxxx/calendars/home/</href> contains: <response> <href>/xxxxx/calendars/home/</href> <propstat> <prop> <resourcetype> <collection/> <calendar xmlns='urn:ietf:params:xml:ns:caldav'/> </resourcetype> ... </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <resourcetype/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> Full response: <?xml version='1.0' encoding='UTF-8'?> <multistatus xmlns='DAV:'> <response> <href>/xxxxx/calendars/</href> <propstat> <prop> <supported-calendar-component-set xmlns='urn:ietf:params:xml:ns:caldav'> <comp name='VEVENT'/> <comp name='VTODO'/> </supported-calendar-component-set> <displayname>xxxxxxxxxx</displayname> <current-user-privilege-set> <privilege> <read/> </privilege> <privilege> <read-free-busy xmlns='urn:ietf:params:xml:ns:caldav'/> </privilege> <privilege> <read-current-user-privilege-set/> </privilege> <privilege> <write/> </privilege> <privilege> <write-properties/> </privilege> <privilege> <write-content/> </privilege> <privilege> <bind/> </privilege> <privilege> <unbind/> </privilege> </current-user-privilege-set> <resourcetype> <collection/> </resourcetype> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <calendar-color xmlns='http://apple.com/ns/ical/'/> <resourcetype/> <calendar-description xmlns='urn:ietf:params:xml:ns:caldav'/> <calendar-timezone xmlns='urn:ietf:params:xml:ns:caldav'/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> <response> <href>/xxxxx/calendars/home/</href> <propstat> <prop> <supported-calendar-component-set xmlns='urn:ietf:params:xml:ns:caldav'> <comp name='VEVENT'/> </supported-calendar-component-set> <displayname>xxxxxxxxxx</displayname> <current-user-privilege-set> <privilege> <read/> </privilege> <privilege> <read-free-busy xmlns='urn:ietf:params:xml:ns:caldav'/> </privilege> <privilege> <read-current-user-privilege-set/> </privilege> <privilege> <write/> </privilege> <privilege> <write-properties/> </privilege> <privilege> <write-content/> </privilege> <privilege> <bind/> </privilege> <privilege> <unbind/> </privilege> </current-user-privilege-set> <calendar-color symbolic-color='__custom__' xmlns='http://apple.com/ns/ical/'>#cca312FF</calendar-color> <calendar-description xmlns='urn:ietf:params:xml:ns:caldav'/> <calendar-timezone xmlns='urn:ietf:params:xml:ns:caldav'><![CDATA[BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Apple Inc.//Mac OS X 10.9.4//EN CALSCALE:GREGORIAN BEGIN:VTIMEZONE TZID:America/Los_Angeles BEGIN:DAYLIGHT TZOFFSETFROM:-0800 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU DTSTART:20070311T020000 TZNAME:GMT-7 TZOFFSETTO:-0700 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0700 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU DTSTART:20071104T020000 TZNAME:GMT-8 TZOFFSETTO:-0800 END:STANDARD END:VTIMEZONE END:VCALENDAR ]] ></calendar-timezone> <resourcetype> <collection/> <calendar xmlns='urn:ietf:params:xml:ns:caldav'/> </resourcetype> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <resourcetype/> <calendar-description xmlns='urn:ietf:params:xml:ns:caldav'/> <calendar-timezone xmlns='urn:ietf:params:xml:ns:caldav'/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> <response> <href>/xxxxx/calendars/notification/</href> <propstat> <prop> <displayname>notification</displayname> <current-user-privilege-set> <privilege> <read/> </privilege> <privilege> <read-free-busy xmlns='urn:ietf:params:xml:ns:caldav'/> </privilege> <privilege> <unbind/> </privilege> <privilege> <read-current-user-privilege-set/> </privilege> </current-user-privilege-set> <resourcetype> <notification xmlns='http://calendarserver.org/ns/'/> <collection/> </resourcetype> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <supported-calendar-component-set xmlns='urn:ietf:params:xml:ns:caldav'/> <calendar-color xmlns='http://apple.com/ns/ical/'/> <resourcetype/> <calendar-description xmlns='urn:ietf:params:xml:ns:caldav'/> <calendar-timezone xmlns='urn:ietf:params:xml:ns:caldav'/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> <response> <href>/xxxxx/calendars/tasks/</href> <propstat> <prop> <supported-calendar-component-set xmlns='urn:ietf:params:xml:ns:caldav'> <comp name='VTODO'/> </supported-calendar-component-set> <displayname>DAVdroid</displayname> <current-user-privilege-set> <privilege> <read/> </privilege> <privilege> <read-free-busy xmlns='urn:ietf:params:xml:ns:caldav'/> </privilege> <privilege> <read-current-user-privilege-set/> </privilege> <privilege> <write/> </privilege> <privilege> <write-properties/> </privilege> <privilege> <write-content/> </privilege> <privilege> <bind/> </privilege> <privilege> <unbind/> </privilege> </current-user-privilege-set> <calendar-color symbolic-color='blue' xmlns='http://apple.com/ns/ical/'>#1badf8FF</calendar-color> <calendar-description xmlns='urn:ietf:params:xml:ns:caldav'/> <calendar-timezone xmlns='urn:ietf:params:xml:ns:caldav'><![CDATA[BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Apple Inc.//Mac OS X 10.9.4//EN CALSCALE:GREGORIAN BEGIN:VTIMEZONE TZID:America/Los_Angeles BEGIN:DAYLIGHT TZOFFSETFROM:-0800 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU DTSTART:20070311T020000 TZNAME:GMT-7 TZOFFSETTO:-0700 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0700 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU DTSTART:20071104T020000 TZNAME:GMT-8 TZOFFSETTO:-0800 END:STANDARD END:VTIMEZONE END:VCALENDAR ]] ></calendar-timezone> <resourcetype> <collection/> <calendar xmlns='urn:ietf:params:xml:ns:caldav'/> </resourcetype> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <resourcetype/> <calendar-description xmlns='urn:ietf:params:xml:ns:caldav'/> <calendar-timezone xmlns='urn:ietf:params:xml:ns:caldav'/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> <response> <href>/509494181/calendars/inbox/</href> <propstat> <prop> <supported-calendar-component-set xmlns='urn:ietf:params:xml:ns:caldav'> <comp name='VEVENT'/> <comp name='VTODO'/> <comp name='VPOLL'/> </supported-calendar-component-set> <current-user-privilege-set> <privilege> <schedule-deliver xmlns='urn:ietf:params:xml:ns:caldav'/> </privilege> <privilege> <read/> </privilege> <privilege> <write-properties/> </privilege> <privilege> <write/> </privilege> <privilege> <write-content/> </privilege> <privilege> <bind/> </privilege> <privilege> <unbind/> </privilege> <privilege> <read-current-user-privilege-set/> </privilege> <privilege> <read-free-busy xmlns='urn:ietf:params:xml:ns:caldav'/> </privilege> </current-user-privilege-set> <resourcetype> <collection/> <schedule-inbox xmlns='urn:ietf:params:xml:ns:caldav'/> </resourcetype> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <displayname/> <calendar-color xmlns='http://apple.com/ns/ical/'/> <resourcetype/> <calendar-description xmlns='urn:ietf:params:xml:ns:caldav'/> <calendar-timezone xmlns='urn:ietf:params:xml:ns:caldav'/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> <response> <href>/xxxxx/calendars/outbox/</href> <propstat> <prop> <supported-calendar-component-set xmlns='urn:ietf:params:xml:ns:caldav'> <comp name='VEVENT'/> <comp name='VTODO'/> </supported-calendar-component-set> <resourcetype> <collection/> <schedule-outbox xmlns='urn:ietf:params:xml:ns:caldav'/> </resourcetype> <current-user-privilege-set> <privilege> <schedule-send xmlns='urn:ietf:params:xml:ns:caldav'/> </privilege> <privilege> <read-current-user-privilege-set/> </privilege> <privilege> <read/> </privilege> </current-user-privilege-set> </prop> <status>HTTP/1.1 200 OK</status> </propstat> <propstat> <prop> <calendar-description xmlns='urn:ietf:params:xml:ns:caldav'/> <calendar-timezone xmlns='urn:ietf:params:xml:ns:caldav'/> </prop> <status>HTTP/1.1 404 Not Found</status> </propstat> </response> Version: Tested on 2015/10/17 Notes: This problem was discovered when developing DAVdroid (CalDAV/CardDAV client) and testing it with iCloud.

For reference and transparency: We have created this report on Apple Bug Reporter on 6 Aug 2015 here: https://bugreport.apple.com/web/?problemID=22169036 Summary: RECURRENCE-ID for exceptions of recurring all-day events should be of type VALUE=DATE, but they have VALUE=DATE-TIME. Steps to Reproduce: Create a recurring all-day event (for instance, daily for 10 days). Create an exception on a particular date, for instance change the title (SUMMARY) Expected Results: # master event: DTSTART;VALUE=DATE:20150804 # exception: RECURRENCE-ID;VALUE=DATE:20150805 Actual Results: # master event: DTSTART;VALUE=DATE:20150804 # exception: RECURRENCE-ID:20150805T000000 As you can see, the RECURRENCE-ID is for VALUE=DATE-TIME, while the original event is of type VALUE=DATE. This causes some clients to ignore the exception and/or add an additional event instead of using this event as an exception. Notes: http://tools.ietf.org/html/rfc5545#section-3.8.4.4 If the value of the “DTSTART” property is a DATE type value, then the value MUST be the calendar date for the recurrence instance. Configuration:

For reference and transparency: We have created this report on Apple Bug Reporter on 23 Feb 2016 here: https://bugreport.apple.com/web/?problemID=24791955 Summary: When creating a calendar by MKCALENDAR without supported-calendar-component-set, iCloud doesn’t set without supported-calendar-component-set by itself. So the without supported-calendar-component-set property stays undefined, which means (RFC 4791): “In the absence of this property, the server MUST accept all component types, and the client can assume that all component types are accepted.” Steps to Reproduce: Create CalDAV collection with MKCALENDAR. Don’t specify supported-calendar-component-set. Use PROPFIND to verify that supported-calendar-component-set is not set. Expected Results: iCloud doesn’t show this collection as “Calendars” and “Reminders”, but only as one of them. Actual Results: CalDAV calendars without supported-calendar-component-set should show up as both “calendars” and “reminders”. Version: iCloud (23 Feb 2016) Notes: Configuration: direct CalDAV requests (curl/command line) Response: This issue behaves as intended based on the following: The first VOBJECT - VEVENT or TODO will decide the type of this container. Please update your bug report to let us know if this is still an issue for you. Our response: I understand this, but I think it’s against the CalDAV specification and just wanted to report it.

For reference and transparency: We have created this report on Apple Bug Reporter on 23 Feb 2016 here: https://bugreport.apple.com/web/?problemID=24791895 Summary: When creating a task list with MKCOL/MKCALENDAR, the calendar-color is ignored. Steps to Reproduce: Create a task list (supported-calendar-component-set only VTODO) with MKCALENDAR or Extended MKCOL. Send along a calendar-color. The calendar-color is ignored. Expected Results: The task list should have the color from the MKCALENDAR request. Actual Results: The color from the MKCALENDAR request is ignored and the task list is assigned a random color. Version: Current iCloud (23 Feb 2016) Notes: This DOES work for calendars with supported-calendar-component-set set to VEVENT only. It doesn’t work for task lists only. Configuration: direct MKCALENDAR/MKCOL requests (curl/command line)

For reference and transparency: We have created this report on Apple Bug Reporter on 6 Sep 2016 here: https://bugreport.apple.com/web/?problemID=28172308 Summary: VCard 3 uses folding for long lines. OS X Server Contacts can’t parse VCard 3 resources with folded PRODID lines. Steps to Reproduce: Upload a VCard 3 with folded PRODID line, like the following: BEGIN:VCARD VERSION:3.0 PRODID:+//IDN bitfire.at//DAVdroid/1.2.3-gplay vcard4android ez-vcard/0.9.1 0 UID:0ea1c5a9-2c93-443d-8672-0e871710203b@owncloud-service-host FN:John Doe N:Doe;John;;; … Expected Results: The VCard should be parsed correctly. Actual Results: VCard is not parsed. Console error messages: Ignored vCard at /remote.php/carddav/addressbooks/principalname/contacts/0ea1c5a9-2c93-443d-8672-0e871710203b%2540owncloud-service-host.vcf because there is no UID property: "BEGIN:VCARD VERSION:3.0 PRODID:+//IDN bitfire.at//DAVdroid/1.2.3-gplay vcard4android ez-vcard/0.9.1 0 UID:0ea1c5a9-2c93-443d-8672-0e871710203b@owncloud-service-host FN:John Doe N:Doe;John;;; TEL;TYPE=home;TYPE=pref:+1555123456789 EMAIL;TYPE=work;TYPE=pref:john.doe@example.com EMAIL;TYPE=home:from-mac@example.com EMAIL:from-davdroid@example.com REV:2016-08-14T13:18:42+00:00 END:VCARD" Version: OS X Server 5.1.5 Notes: Line folding is defined in RFC 2426 section 2.6, which refers to RFC 2425 section 5.81. Lines longer than 75 characters even SHOULD be folded. Configuration: This report was marked as a duplicate and the problem has apparently been fixed.

For reference and transparency: We have created this report on Apple Bug Reporter on 8 June 2016 here: https://bugreport.apple.com/web/?problemID=26696591 Summary: If you upload a contact group (X-ADDRESSBOOKSERVER-KIND: group), iCloud insists that the VCard must have a FN and a N (as specified in VCard 3). iCloud seems to take the group name from the structured name (N) instead of the formatted name (FN). Additionally, it doesn’t only take the first component of the structured name, but the whole line as a string (which should not happen). N represents the structured name and these representations mean the same: N:Family Name,,,, N:Family Name When a group with the first version, iCloud will display “Family Name,” as group name. Steps to Reproduce: Upload (PUT) a contact group with these properties: N:Family Name,,,, N:Family Name Expected Results: iCloud will show a group “Family Name,” Actual Results: iCloud should show a group “Family Name” (by FN, not N). Version: iCloud on 8 Jun 2016 Notes: This problem was found while developing DAVdroid. Configuration: – Update from 12 Oct 2018: Typo in steps to reproduce. Should be: N:Family Name,,,, FN:Family Name

For reference and transparency: We have created this report on Apple Bug Reporter on 16 Mar 2016 here: https://bugreport.apple.com/web/?problemID=25197744 Summary: REPORT calender-query can be used with time-range to filter results by time. This is also applicable to VTODO collections (task lists). To determine whether a VTODO is within the requested time, the algorithm from page 92 [http://tools.ietf.org/html/rfc4791#page-92] must be used. According to this algorithm, VTODOs which do not have any of DTSTART, DURATION, DUE, COMPLETED and CREATED, the overlapping value is always TRUE, meaning that those tasks should always be returned regardless of which time range is requested. iCloud (16 Mar 2016) currently does NOT return VTODOs which do not have any of DTSTART, DURATION, DUE, COMPLETED and CREATED. Steps to Reproduce: Create a new task list (MKCOL) Add a new task without DTSTART, DURATION, DUE, COMPLETED and CREATED. Do REPORT calendar-query with time-range start="<some time>". Expected Results: All tasks without DTSTART, DURATION, DUE, COMPLETED and CREATED should be returned. Actual Results: Tasks without DTSTART, DURATION, DUE, COMPLETED and CREATED are not returned. Version: iCloud, 16 Mar 2016 Notes: Configuration: iCloud, server: https://p23-caldav.icloud.com/ Apple engineering has responded that we can use PROPFIND (which would list all iCalendars, not only VTODOs) and that they can’t fix it because We need to make this exception.

According to Apple, the bug report has been closed because I did not provide an iCloud Apple ID.

For reference and transparency: We have created this report on Apple Bug Reporter on 12 Oct 2018 here: https://bugreport.apple.com/web/?problemID=45222051 Hello, When iCloud send 412 Precondition failed on an invalid sync-token, it uses “text/plain” instead of “application/xml” MIME type for the XML error description. Steps to reproduce: Send an HTTP REPORT sync-collection [https://tools.ietf.org/html/rfc6578#section-3.2] request with an invalid (outdated, etc.) sync-token to iCloud: REPORT url=https://p59-contacts.icloud.com/xxxx/carddavhome/card/ <?xml version='1.0' encoding='UTF-8' ?><sync-collection xmlns="DAV:"><sync-token>this-is-invalid</sync-token><sync-level>1</sync-level><prop><getetag /></prop></sync-collection> Actual result: Server responds with 412 Precondition Failed and valid-sync-token XML precondition element [https://tools.ietf.org/html/rfc6578#section-3.2] <-- 412 Precondition Failed Server: AppleHttpServer/2f080fc0 Date: Fri, 12 Oct 2018 10:17:59 GMT Content-Type: text/plain; charset=UTF-8 Connection: keep-alive X-Apple-Jingle-Correlation-Key: xxxxxxxxxxxxx apple-seq: 0 apple-tk: false Apple-Originating-System: UnknownOriginatingSystem X-Responding-Instance: carddav:15900201:st42p59ic-tyfb13213201:8001:1819B41:51222b91b Via: xrail:st13p00ic-zteu25283601.me.com:8301:18H64:grp62 Strict-Transport-Security: max-age=31536000; includeSubDomains; via: icloudedge:br30p01ic-zteu03012201:7401:18RC550:Berlin X-Apple-Request-UUID: xxxxxxxxxxxxxxxx access-control-expose-headers: X-Apple-Request-UUID access-control-expose-headers: Via <?xml version='1.0' encoding='UTF-8'?> <error xmlns='DAV:'> <valid-sync-token/> </error> As you can see, the Content-Type is “text/plain; charset=UTF-8”, although it should be application/xml or text/xml [https://tools.ietf.org/html/rfc4918#section-8.2]. This causes clients like our software DAVdroid to not parse the response as XML, so that valid-sync-token is not recognized as the reason why the request has failed, so DAVdroid does NOT retry without sync token, but aborts with an error message. So the sync has failed with an error message. Expected result: Same response, but with Content-Type: application/xml [https://tools.ietf.org/html/rfc4918#section-8.2].