For the next in my continuing Exchange saga, let's talk 502 errors. I've
got a couple different instances.
1) ActiveSync sends periodic 'Ping' requests to implement its "server
push" feature. If I understand the process correctly, the client sends
an empty (Content-Length: 0) keep-alive HTTP request and tries to see
how long the server+network honor the session. It uses a back-off
algorithm to eventually settle on a timing value that it knows the
network can support: if the keep-alive expires cleanly, they up the ante
and repeat; if the HTTP session aborts, they drop it down to the
previous success and lock in the refresh rate. From that point forward,
they've got a sync window and continue to issue Pings at that duration.
That way, if the Ping aborts, it is a signal that a 'Sync' is needed
because "server push" has new data.
What I'm actually seeing is that the system is never able to settle on a
consistent keep-alive sync window as MS might like. The Ping, or string
of Pings, might last minutes or could only be seconds. When the Ping
ultimately fails, the system does a Sync even though there may be
nothing new. The end result is that it is less like "server push" and
more like polling at a variable rate.
The users don't really notice or care since they still get their updates
promptly. It's hardly catastrophic for me, but I could envision that the
variable-polling behavior might be slightly more taxing as the number of
users scale upward. But I'm curious if there's any Squid debug I can add
that might reveal why the session durations seem to vary so much? At
11,2 level, the only thing I see is:
2013/08/19 00:46:51 kid1| WARNING: HTTP: Invalid Response: No object data received forhttps://mail.domain.com/Microsoft-Server-ActiveSync?User=user&DeviceId=ApplF4KKR4GLF199&DeviceType=iPad&Cmd=Ping AKA mail.domain.com/Microsoft-Server-ActiveSync?User=user&DeviceId=ApplF4KKR4GLF199&DeviceType=iPad&Cmd=Ping
To which Squid replies back to the client as 502 Bad Gateway.
X-Squid-Error is ERR_ZERO_SIZE_OBJECT.
2) Next problem is OWA (WebMail). OWA is designed to mimic Outlook, so
if Outlook can support 10Meg attachments, so can OWA. A user tries to
send a large attachment. Unlike the ActiveSync problem I previously
posted about, UploadReadAhead does not seem to enter into the equation -
possibly because the POST is redirected to an /EWS/ proxy. It happily
chunks well past the ActiveSync threshold, but at some point the
connection may still fail:
2013/08/21 07:41:07.616 kid1| http.cc(1172) readReply: local=proxy.IP:42891 remote=Exchange.IP:443 FD 39 flags=1: read failure: (32) Broken pipe.
To which Squid replies back to the client as 502 Bad Gateway.
X-Squid-Error is ERR_READ_ERROR 104.
I know Squid doesn't touch the data, and thus doesn't care about
transaction size. But is there anything more I can do to minimize all
possible drops & connection timeouts, particularly with large POSTs? I'm
not saying the drops are Squid's fault, I just want to idiot-proof the
setup on this end as much as possible.
3) Final example is RPC-over-HTTPS. I routinely see 502s on "connection
reset by peer" (RSTs seem to be par for the course on Windows systems).
But I've also seen ERR_READ_ERROR 104 on a "No error" error.
2013/08/19 21:09:37.239 kid1| http.cc(1172) readReply: local=proxy.IP:58798 remote=Exchange.IP:443 FD 44 flags=1: read failure: (0) No error..
What could this possibly indicate?
--bill
