[CalendarServer-users] Connection aborted - took too long to close

[Jacques Distler]

> On Feb 14, 2015, at 12:55 PM, Andre LaBranche <dre at apple.com> wrote:
> 
> Have you proven that the server is seeing ACKs and things from the client in the connections that are dropping? I don't think this is some kind of delayed or coalesced ACK thing, but maybe.

I guess I will have to find a way to get a useful-looking dump of the TCP connection. But simply changing which user's calendar I fetch changes the result.

Fetching

      https://golem.ph.utexas.edu:8443/calendars/users/XXXX/calendar/

succeeds. Fetching

      https://golem.ph.utexas.edu:8443/calendars/users/YYYYY/calendar/

starts to download data (which, as I said, I can see, as the browser renders partial content), but eventually times out.

> Given that it appears that the server is the one timing out the connection, that leads me to believe that perhaps it thinks the connection has been abandoned.

For whatever it's worth, here are the HTTP headers for the connection that timed out:

---------------------------------------------
GET /calendars/users/YYYYY/calendar/ HTTP/1.1
Host: golem.ph.utexas.edu:8443
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Authorization: Basic ZGlzdGxlcjpvQTlnNDUjeGc=
Connection: keep-alive
Range: bytes=126976-
If-Range: "8594b290ec42129aea36d880441319bf"
Cache-Control: max-age=0

HTTP/1.1 206 Partial Content
Etag: "8594b290ec42129aea36d880441319bf"
Accept-Ranges: bytes
Last-Modified: Fri, 13 Feb 2015 21:17:20 GMT
Date: Sat, 14 Feb 2015 19:28:55 GMT
Strict-Transport-Security: max-age=604800
Content-Length: 382282
Content-Range: bytes 126976-509257/509258
Content-Type: text/html;charset=utf-8
Server: Twisted/12.3.0 TwistedWeb/9.0.0
DAV: 1, access-control, calendar-access, calendar-schedule, calendar-auto-schedule, calendar-availability, inbox-availability, calendar-proxy, calendarserver-private-events, calendarserver-private-comments, calendarserver-sharing, calendarserver-sharing-no-scheduling, calendar-query-extended, calendar-default-alarms, calendar-managed-attachments, calendarserver-partstat-changes, calendar-no-timezone, calendarserver-recurrence-split, addressbook, extended-mkcol, calendarserver-principal-property-search, calendarserver-principal-search, calendarserver-home-sync
Connection: close
------------------------------------------

Now here's the funny thing. I don't think that the Server actually sent all the bytes it promised. When I try again to fetch the URL, here is what the headers look like:

------------------------------------------
GET /calendars/users/YYYYY/calendar/ HTTP/1.1
Host: golem.ph.utexas.edu:8443
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Authorization: Basic ZGlzdGxlcjpvQTlnNDUjeGc=
Connection: keep-alive
Range: bytes=190464-
If-Range: "8594b290ec42129aea36d880441319bf"
Cache-Control: max-age=0

HTTP/1.1 206 Partial Content
Server: Twisted/12.3.0 TwistedWeb/9.0.0
Content-Length: 318794
Content-Range: bytes 190464-509257/509258
Etag: "8594b290ec42129aea36d880441319bf"
Date: Sat, 14 Feb 2015 19:42:43 GMT
Last-Modified: Fri, 13 Feb 2015 21:17:20 GMT
DAV: 1, access-control, calendar-access, calendar-schedule, calendar-auto-schedule, calendar-availability, inbox-availability, calendar-proxy, calendarserver-private-events, calendarserver-private-comments, calendarserver-sharing, calendarserver-sharing-no-scheduling, calendar-query-extended, calendar-default-alarms, calendar-managed-attachments, calendarserver-partstat-changes, calendar-no-timezone, calendarserver-recurrence-split, addressbook, extended-mkcol, calendarserver-principal-property-search, calendarserver-principal-search, calendarserver-home-sync
Strict-Transport-Security: max-age=604800
Accept-Ranges: bytes
Content-Type: text/html;charset=utf-8
Connection: close
----------------------------------------------------------

Note that the requested byte range has changed --- as if the client got bytes 126976-190463  in the previous response.

> If we had a reproducible case of this, we could debug it, but as it stands, you are the only source of diagnostic data for this issue.

Sorry I haven't been able to provide more useful input.

JD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.macosforge.org/pipermail/calendarserver-users/attachments/20150214/6bfe79b4/attachment-0001.sig>