<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Update:<br>
<br>
I tried with my son's phone which is running 11.0 and I can add a
new account against my server just fine.<br>
<br>
I just updated my phone to 11.1.1 and now it works fine.<br>
<br>
So, I don't know if this problem was with 11.0.3 or with my phone.<br>
<br>
I can probably get a test account setup at FastMail if you want to
do some diagnosis.<br>
<br>
<br>
<div class="moz-cite-prefix">On 11/10/2017 09:48 AM, Ken Murchison
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:45b21a9e-3dfd-3e8c-6467-57301df1f37b@fastmailteam.com">Hi
Sean, <br>
<br>
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. <br>
<br>
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. <br>
<br>
<br>
On 11/09/2017 11:21 PM, Sean Seguin wrote: <br>
<blockquote type="cite">Does this reproduce on pre-iOS 11.0.3
builds? <br>
<br>
~Sean <br>
<br>
<blockquote type="cite">On Nov 8, 2017, at 12:42 PM, Ken
Murchison <a class="moz-txt-link-rfc2396E"
href="mailto:murch@fastmailteam.com"><murch@fastmailteam.com></a>
wrote: <br>
<br>
Has anyone had issues adding a new CalDAV account on iOS
11.0.3? <br>
<br>
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. <br>
<br>
Here is the last request/response that I get: <br>
<br>
<br>
OPTIONS /dav/principals/user/user01/ HTTP/1.1 <br>
Host: 192.168.1.209 <br>
Content-length: 0 <br>
Connection: keep-alive <br>
Accept: */* <br>
User-agent: iOS/11.0.3 (15A432) accountsd/1.0 <br>
Accept-language: en-us <br>
Authorization: Basic ... <br>
Accept-encoding: gzip, deflate <br>
<br>
HTTP/1.1 200 OK <br>
Date: Thu, 02 Nov 2017 00:06:56 GMT <br>
Connection: Upgrade <br>
Upgrade: h2c <br>
Cache-Control: no-cache <br>
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
<br>
DAV: 1, 2, 3, access-control, extended-mkcol, resource-sharing
<br>
DAV: calendar-access, calendar-auto-schedule <br>
DAV: calendar-query-extended, calendar-availability,
calendar-managed-attachments <br>
DAV: calendarserver-sharing, inbox-availability <br>
DAV: addressbook <br>
Allow: OPTIONS, GET, HEAD <br>
Allow: PROPFIND, REPORT, COPY <br>
Content-Length: 0 <br>
<br>
<br>
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. <br>
<br>
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? <br>
<br>
<br>
<br>
-- <br>
Ken Murchison <br>
Cyrus Development Team <br>
FastMail Pty Ltd <br>
<br>
_______________________________________________ <br>
caldeveloper-l mailing list <br>
<a class="moz-txt-link-abbreviated"
href="mailto:caldeveloper-l@lists.calconnect.org">caldeveloper-l@lists.calconnect.org</a>
<br>
<a class="moz-txt-link-freetext"
href="http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org">http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org</a>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
<pre class="moz-signature" cols="72">--
Kenneth Murchison
Cyrus Development Team
FastMail Pty Ltd</pre>
</body>
</html>