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