[caldeveloper-l] iOS 11.03.3 Calendar problem

[Sean Seguin]

Weird.  If you can set up a test account, we could test against it too.

~Sean

> On Nov 10, 2017, at 7:26 AM, Ken Murchison <murch at fastmailteam.com> wrote:
> 
> Update:
> 
> I tried with my son's phone which is running 11.0 and I can add a new account against my server just fine.
> 
> I just updated my phone to 11.1.1 and now it works fine.
> 
> So, I don't know if this problem was with 11.0.3 or with my phone.
> 
> I can probably get a test account setup at FastMail if you want to do some diagnosis.
> 
> 
> On 11/10/2017 09:48 AM, Ken Murchison wrote:
>> Hi Sean, 
>> 
>> I'm 99% sure it wasn't an issue on 10.x.  Its definitely not an issue on 9.3.5 on an older iPad mini. 
>> 
>> I don't recall if I created a new account on 11.0.2, but an existing one worked fine.  I see the same initial PROPFIND + OPTIONS behavior on 11.1. 
>> 
>> 
>> On 11/09/2017 11:21 PM, Sean Seguin wrote: 
>>> Does this reproduce on pre-iOS 11.0.3 builds? 
>>> 
>>> ~Sean 
>>> 
>>>> On Nov 8, 2017, at 12:42 PM, Ken Murchison <murch at fastmailteam.com> <mailto:murch at fastmailteam.com> wrote: 
>>>> 
>>>> Has anyone had issues adding a new CalDAV account on iOS 11.0.3? 
>>>> 
>>>> Looking at telemetry on my Cyrus server, it only does a PROPFIND on .well-known/caldav to find the current-user-principal and then does an OPTIONS on that URL.  That's it.  It never does any other PROPFIND/REPORT to discover calendars. 
>>>> 
>>>> Here is the last request/response that I get: 
>>>> 
>>>> 
>>>> OPTIONS /dav/principals/user/user01/ HTTP/1.1 
>>>> Host: 192.168.1.209 
>>>> Content-length: 0 
>>>> Connection: keep-alive 
>>>> Accept: */* 
>>>> User-agent: iOS/11.0.3 (15A432) accountsd/1.0 
>>>> Accept-language: en-us 
>>>> Authorization: Basic ... 
>>>> Accept-encoding: gzip, deflate 
>>>> 
>>>> HTTP/1.1 200 OK 
>>>> Date: Thu, 02 Nov 2017 00:06:56 GMT 
>>>> Connection: Upgrade 
>>>> Upgrade: h2c 
>>>> Cache-Control: no-cache 
>>>> Server: Cyrus-HTTP/3.1.2-155-ga56b840c7-dirty Cyrus-SASL/2.1.26 LibXML2.9.4 Nghttp2/1.21.1 OpenSSL/1.1 Zlib/1.2.11 SQLite/3.20.1 LibiCal/2.99 ICU4C/57.1 Jansson/2.10 
>>>> DAV: 1, 2, 3, access-control, extended-mkcol, resource-sharing 
>>>> DAV: calendar-access, calendar-auto-schedule 
>>>> DAV: calendar-query-extended, calendar-availability, calendar-managed-attachments 
>>>> DAV: calendarserver-sharing, inbox-availability 
>>>> DAV: addressbook 
>>>> Allow: OPTIONS, GET, HEAD 
>>>> Allow: PROPFIND, REPORT, COPY 
>>>> Content-Length: 0 
>>>> 
>>>> 
>>>> I've made all kind of code tweaks on my server in an effort to trigger some different behavior with no joy.  I've removed the Server and Upgrade headers.  I've merged the multiple DAV and Allow headers into single headers. 
>>>> 
>>>> Any ideas?  Is there some token that iOS is now looking for in the OPTIONS response?  Is there some weird switch on iOS that disables calendar discovery? 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Ken Murchison 
>>>> Cyrus Development Team 
>>>> FastMail Pty Ltd 
>>>> 
>>>> _______________________________________________ 
>>>> caldeveloper-l mailing list 
>>>> caldeveloper-l at lists.calconnect.org <mailto:caldeveloper-l at lists.calconnect.org> 
>>>> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org <http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org> 
>> 
> -- 
> Kenneth Murchison
> Cyrus Development Team
> FastMail Pty Ltd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20171110/22854a57/attachment-0001.html>