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
> the OPENSOCKETFUNCTION callback.

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

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html