> I think the keeping if the conn->bits.proxy_connect_closed set to true is
the
> _actual_ problem here. It should probably be assigned to false
unconditionally
> in the beginning of ConnectPlease() or similar.

> Won't that too fix the problematic case you experienced?

Unfortunately that didn't do the trick, at lease not using the patch you've
suggested - I still encountered the endless loop. I'll try to reproduce the
scenario.

I spent the better part of the day trying to hunt some nasty proxy
authentication bug, but to no avail. I have a couple of questions though:

1. It seems that Curl_proxyCONNECT doesn't handle well the situation where
the proxy closes the socket during the negotiation phase IF not Connection
or Proxy-Connection are given. The proxy I'm referring to (Netcache with
basic authentication) closes the socket after the 407 reply but does not
send any of these headers. I think the problem lies in the line (http.c
:1304)

          res = Curl_read(conn, tunnelsocket, ptr, BUFSIZE-nread,
&gotbytes);

If both res and gotbytes are zero the socket was probably closed and this
should be handled by the code and not be treated as an error. I have the
code to handle it, but it is not yet fully functional, probably due to the
following issues.

2. When Curl_proxyCONNECT fails and the socket is closed (even with the
"normal" Connection header), I noticed some inconsistency (or at least it
looks like it to me). If Curl_proxyCONNECT was called indirectly by
Curl_async_resolved, the closed socket situation is properly handled and the
2nd request (with the authentication data) is properly sent. However, since
the socket connect can take a bit, Curl_proxyCONNECT can also be called
(again indirectly) from Curl_connect in which case the socket closure is not
correctly handled. I think the difference lies in the multi state-machine
implementation but I'm a bit lost there.

I would be happy to get your opinion regarding these issues.

Cheers,
Shmul
Received on 2007-07-12