[caldeveloper-l] iOS 11.03.3 Calendar problem

[Ken Murchison]

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> 
>>> 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
>>> 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/286c5b82/attachment.html>