cURL / Mailing Lists / curl-library / Single Mail


Re: Change Request

From: Keean Schupke <>
Date: Mon, 7 Feb 2011 23:19:27 +0000

On 7 February 2011 22:11, Daniel Stenberg <> wrote:

> 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
> work.
> 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:
> Etiquette:

The OPENSOCKETFUNCTION returns the socket as its return value, so unless a
structure is returned then I don't see how this can easily be done.

We could test the socked with "getpeername" to see if it is connected? If
getpeername(...) returns an error the socket is not connected. Something

if (getpeername(socket, &addr, len) < 0) {
    rc = connect(socket, &addr, len);


List admin:
Received on 2011-02-08