On Thu, 12 Jul 2007, Shmulik Regev wrote:

>> 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.

Hm, then I must've misunderstood the flow that lead to the problem your patch
addressed... I was trying to prevent the problem from happening rather than
surviving the effects from it. BTW, I committed my patch just now but I'll
re-evaluate it's value with input from you.

> 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.

Yes, if both are zero that's most likely a fine close that we should treat as
such. Of course we should make an effort to behave and continue working
properly even for this case.

> 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.

So you're using asynch dns resolves to connect over a proxy? The resolve is
thus for the proxy name, right? (Just asking to get some things straight in my
head.)

In the Curl_connect() case, it is done because the name resolve is fast enough
or done synchronously, as otherwise it is done from Curl_async_resolved() when
the name finally is resolved.

I don't think I follow you about the "socket closure is not correctly
handled". What socket closure? You mean the one that happens in the middle of
Curl_proxyCONNECT() ? The only "handling" of that situation is what is done in
lib/url.c:SetupConnection(). Possibly that is not enough...

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html