On Tue, 6 Nov 2001, john lask wrote:

[ quick summary: there's at least one known proxy that sends a trailing zero
  byte in the initial CONNECT response, which curl makes OpenSSL deal
  with, which then fails and thus the connect gets cancelled. ]

Thanks for being patient!

> The only thing that I could think of was the way in which I have set it up -
> that is:
>
> At termination of the httptunnel proc - the read buffer can be left in
> either of two states.
> a) Nothing more to be read
> b) unread data in buffer <-- see point 2
>
> Since curl is not issuing any tcp request after the initial proxy
> connect, the data in the buffer can only have been placed there as part
> of the acknowledgement from the HTTP proxy.
>
> In priciple if the proxy is operating according to the RFC state b)
> should never occur! - so if we detect a state b) then the proxy is in
> error and we need to do something about it.

Mmmm. I'm slowly starting to realize that you're absolutetely correct! Since
the CONNECT request is just setting up a tunnel through the proxy, it really
can't pass anything else but the response back in that situation, as we have
not issued anything to the remote server (through the tunnel).

I'm sorry for being a bit slow.

> I therefore concluded that it was safe to clear any unread data from the
> read buffer, since it would have been placed there as part of the
> acknowledgement.

Yes. I am now fully on your side of this. We could very well read all data it
passes to us.

May I suggest that we re-write the Curl_ConnectHTTPProxyTunnel() function to
receive the response in much bigger chunks (with proper timeout support),
pretty much how the Curl_GetFTPResponse() already works? It'll make it a lot
faster and it will get everything, including any trailing zero, without he
need of a ioctl() or similar that'll cause portability issues.

Would you be able to make such a re-write?

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/