cURL / Mailing Lists / curl-library / Single Mail


Re: Change Request

From: Daniel Stenberg <>
Date: Mon, 7 Feb 2011 23:11:21 +0100 (CET)

On Mon, 7 Feb 2011, Keean Schupke wrote:

Thanks for your suggestions and willingness to help us improve libcurl!

> I am working on TCP tunnelling, and want to use libcurl for HTTP over the
> tunnel. I can establish the tunnel in the OPENSOCKETFUNCTION callback, but
> curl will fail with an error when it tries to connect the socket I have
> returned (because it is already connected).
> The OPENSOCKETFUNCTION already has access to all the information it needs to
> establish the tunnel, so all I need is for curl to use the already connected
> socket.
> With a small change to lib/connect.c:

Please, use diff -u to make a unified diff when you want to show a change.

>> if ((rc == -1) && (SOCKERRNO == EISCONN)) {
>> rc = 0;
>> }

> Which makes it ignore only the specific (EISCONN) error, I can do everything
> I want using the OPENSOCKETFUNCTION.

First, EISCONN is not portable enough. Secondly, I don't think we need to
limit ourself to force a connect() that must fail in this manner for this to

Can't we instead add a new return code to the CURLOPT_SOCKOPTFUNCTION callback
that asks libcurl to not do connect() on the socket? Like "connect already
done, don't bother to do it".

> Is this patch acceptable as it is, or if not, is there a better way to do
> this that would be accepted. I think the ability to tunnel the HTTP
> connection is useful and generic enough, and only requires a small
> modification as most of the functionality required is already provided by

What do you think about my minor change to the proposal? It is a very small
change as well, and it can be introduced in libcurl with backward
compatibility (since the callback is documented to use 1 to "signal an
unrecoverable error", 0 on success and no other return codes are defined).

List admin:
Received on 2011-02-07