Okay so the fix for the bug that I mentioned before introduced a much worse
bug (That's what I get for not knowing exactly what is going on). This new
bug causes the system to keep all threads alive for the length of the proxy
so with enough sites visited the computer the proxy is running on becomes
useless (100% processor load). I now understand that the reason they never
exit is because the connection is never getting shutdown properly as far as
the TLS standard is concerned, so the fix I put in was to basically ignore
that, and keep going.
But alas, that didn't work for long. My question is why is the session
getting reset before I can upload a file? Is there some sort of a watchdog
timer that I am neglecting to poke before the connection is reset?
Any help would be appreciated.
Thanks,
Sam
On Mon, Aug 30, 2010 at 12:49 PM, Sam Jantz <sjan...@gmail.com> wrote:
> 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
>
>
--
Sam Jantz
Software Engineer
