> On Feb 14, 2015, at 12:55 PM, Andre LaBranche <d...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
