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 openssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
--
Sam Jantz
Software Engineer
