> The goal is to try to eliminate one thing at a time. What this test shows is > that the problem wasn't some intermediary HTTP proxy that was causing a > problem. > > The next thing to do is try without SSL to eliminate any possible buffering > issues with the SSL stack. So can you enable non-SSL access in the plist (and > disable the RedirectHTTPToHTTPS setting too) and try running curl locally > against port 8008 and see if you get the same behavior. Also, when the curl > hangs, trying running a netstat and filter on the port. I would like to see > if there is any write data pending on the server's socket.
OK, *that* produced something interesting. Using curl on the server, the
Response DID return the entire resource.
Here are the headers:
HTTP/1.1 200 OK │·
Accept-Ranges: bytes
Date:
Sun, 15 Feb 2015 19:02:47 GMT
ETag:
"81366bb1ab22b568dec1c1d79b156510"
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 │·
Content-Type: text/html;charset=utf-8
Last-Modified: Sun, 15 Feb 2015 04:36:45 GMT
Server: Twisted/12.3.0 TwistedWeb/9.0.0
Content-Length: 509580
Connection: close
So, evidently, the problem lies somewhere in the SSL stack?
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
