> From: owner-openssl-us...@openssl.org On Behalf Of Sam Jantz > Sent: Friday, 27 August, 2010 18:16
> I have a question concerning Keep-Alives. I'm writing a SSL proxy > (which is working great except for this issue) and every time I > [POST about 470KB rather than about 18KB] the connection resets, > and it gets caught in an infinite retransmit loop. <snip> > This behavior is only implemented in Firefox. In the other browsers > it seems to fail out with some error about unexpected reset. > Is there some parameter that I can set when establishing > the SSL connection that will allow me to wait for larger transfers without reseting? 1. This has nothing to do with "keep-alives". HTTP 1.1 "keep-alive" is a passive feature; it doesn't do anything, instead if agreed the server REFRAINS FROM closing the connection as it would for 1.0. 2. It sounds like the browser is getting RST. (Or to be exact, getting an error from the OS that *it* got RST.) Firefox might respond to this differently than other browsers, by retrying; I don't have time to test. If so, the RST is caused by your proxy doing something abnormal, most likely dying. Check your code for bugs, and/or your logs -- your program does have logging and diagnostic code in it, like any well-designed program, right? 3. Or do you think the proxy is getting RST "from" gmail? I am 99.99% certain google wouldn't have a problem that would do that, although it isn't completely impossible. It's much more likely to be some network (mis)"feature" between you and gmail, like a firewall, NAT box, access controller, "transparent" (but not really) cache, etc. Try without your proxy, but with a client (i.e. browser) on the machine where the proxy is, to the same server with the same amounts of data (or at least reasonably close). If you can, try from different places in the Internet, like from home or a Starbucks versus the company office. 4. SSL itself has no timelimits; it will wait forever, or until the underlying TCP connection fails. (If a remote host just dies without closing properly, TCP may detect this in anywhere from a few minutes to many hours or days, depending.) An application *using* SSL might have a timelimit; if so you have to look to that program as to how, and whether, you can change it. And sometimes a firewall or NAT box or such has an "idle" timeout, where it will terminate your connection if it isn't used for an "excessive" period of time, and some netadmins have a crazy idea what is "excessive"; but I've never seen less than 15 minutes, which I expect is not the case in your example. The really awful ones do this silently, or by faking FIN; the ones that fake(?) RST at least give you a detectable error. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
