On Tue, 12 May 2015, Sean Boudreau wrote:
I ran into a client that could repeatedly get into a tight loop in the do {
} while loop in multi_runsingle() while in state WAITPROXYCONNECT. While in
this state conn->bits.proxy and conn->bits.httpproxy were 0 but
conn->bits.bits.tunnel_proxy was set. conn->tunnel_state[FIRSTSOCKET] was
TUNNEL_INIT. I don't think simply checking tunnel_proxy as per the attached
suggested diff is sufficient as it's possible this gets set via the
CURLOPT_HTTPPROXYTUNNEL option while the others remain 0.
Thanks for this Sean!
Can you figure out how this happens? The only way I can think of right now is
when you enable proxy tunnel but do not tell libcurl to use a HTTP proxy. Is
that what your application did?
I think I would prefer to make sure the situation doesn't occur in the first
place rather than try to add checks for it. Mostly because I fear we either
have this same flaw somewhere else or we risk introducing it again in the
future.
Thoughts?
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
