Hello Daniel,

Friday, September 15, 2006, you wrote:

>> It seems that handleSock4Proxy and handleSock5Proxy has one problem while
>> receiving response from SOCKS proxy. Both of them uses Curl_read() to read
>> the response, but when proxy sends the response byte-by-byte (just like my
>> sample SOCKS server) Curl_read() sometimes returns only one byte instead of
>> several stated in buffersize.
> No, Curl_read() reads as many bytes as it is provided by the TCP layer (and
> that fits in the buffer) so if it reads only one byte there was only byte to
> read!
Yes, that's what I'm saying about. My sample SOCKS server sending
response exactly byte-by-byte and as a result of this Curl_read() have
time to read only one byte. Even more I have added delay between
bytes sending to my test server to catch this bug always.

>> And it causes failure of these functions. For example url.c:1989
> The line numbers are much changed since last release, but I figure you mean
> one of the socks functions?
Yes, I mean one of check like this:

    /* Receive response */
    result = Curl_read(conn, sock, (char *)socksreq, packetsize, &actualread);
    if ((result != CURLE_OK) || (actualread != packetsize)) {
      failf(conn->data, "Failed to receive SOCKS4 connect request ack.");
      return 1;
    }

>> The only way I have found to solve this problem is to add something like
>> Curl_read_all() function that performs Curl_read() until entire buffer will
>> be filled. Is this a good solution?
> No, it would possibly make it work better than now but it would be far away
> from a good solution.
It makes work much better for me. :) The bug is gone away.
So, here is my patch with such changes. I'm agree that it is no so good
solution, but I think it is better than nothing. Because the bug is
really exists and easily reproducible.

>> And may be hadnleSocks* functions in case of failure must to
>> return CURLE_COULDNT_CONNECT instead of 1 ? Because ConnectPlease()
>> function verifies only this return value to determine the failure.
>> But CURLE_COULDNT_CONNECT == 7 and it returns CURLE_OK even if
>> handleSocks failed (url.c:2324)
> The handleSock[45]Proxy functions are called from ConnectPlease() and that
> function treads a non-zero return code as error and will then return
> CURLE_COULDNT_CONNECT upstream.
Oh, sorry. It's my mistake.

-- 
Best regards,
 Dmitriy                            mailto:dsergeyev_at_issart.com