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
