Dave, Thank you for the clarification on HTTP keep-alives.
I have just now fixed the bug. The source of the problem was an SSL_read call on the client half of the proxy. This was triggering an error SSL_ERROR_SYSCALL with a ret of zero. According to the documentation this is normally caused by an improperly shutdown SSL connection, however rescheduling the read for when the socket was ready (using a select statement) fixed this issue. I have tested it up to a 5MB file, and it works perfectly. I am a little confused on why I was getting the error in the first place still though. What would cause SSL_ERROR_SYSCALL to be flagged, and have an empty error queue if the socket was not closed improperly on the other side? On Sun, Aug 29, 2010 at 11:06 PM, Dave Thompson <dthomp...@prinpay.com>wrote: > > 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 firstname.lastname@example.org > Automated List Manager majord...@openssl.org > -- Sam Jantz Software Engineer