Yep, HttpSM::setup_blind_tunnel is being called less that
SSLNextProtocolAccept::mainEvent. Sorry for confusion, I fixed comment
recently.
stiple@proxy-test-proxy:~$ cat traffic.out | grep "tunnel" | wc -l
19829
stiple@proxy-test-proxy:~$ cat traffic.out | grep "mainEvent" | wc -l
19833
2015-03
On 3/20/2015 9:39 AM, Lev Stipakov wrote:
Hi Susan,
I use master branch (commit b12b0399f0aeb85cec3a622ebf61e541d9c29912),
so I assume that TS-3424 is fixed there.
I have tried your suggestion from TS-3453 but unfortunately it didn't
help. Moreover, in my use case (transparent SSL proxy) code
Hi Susan,
I use master branch (commit b12b0399f0aeb85cec3a622ebf61e541d9c29912),
so I assume that TS-3424 is fixed there.
I have tried your suggestion from TS-3453 but unfortunately it didn't
help. Moreover, in my use case (transparent SSL proxy) code branch “if
(!vc->getSSLHandShakeComplete()) {
Interesting. It appears that we are dropping the reenable action from
your thread sometimes. I'm guessing there is an issue with the
readReschedule.
I'll give this a go in my transparent dev environment. A couple things
you might want to look at.
* Brian uncovered a fairly serious SSL sta
Hello,
I made a simple plugin that sets up TS_SSL_SNI_HOOK and creates a
blind tunnel from a separate thread. With low load everything works
fine, but with moderate load (100 simultaneous users, each user sends
200 HTTPS requests) I see somewhat strange behavior.
On a client side I use Tsung, whi
