On 1/13/06, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Thu, 12 Jan 2006, Allen Chan wrote:
>
> > //connect method send
> > nResult = send( s, buff, strlen( buff ), 0 );
> >
> > Pretty simple, I know. I really can't see any difference why this one would
> > go through whereas curl could not.
>
> Mysterious are indeed the ways of those programs. Contact their support and
> ask. After all, I guess someone in your surrounding actually paid for that...
>
The PC that I am using is from DELL and Norton Internet Security came
pre-installed. I am actually more interested in implementing the
abilities of that aforementioned program since we can't go about
disabling firewall for curl, though unfortunately it now seems there
was nothing special about it at all. I will have to look into this
some more.

> > Unfortunately, regarding CURLOPT_URL, CURLOPT_HTTPPROXYTUNNEL, then
> > CURLOPT_CUSTOMREQUEST, the resulting GET-turned-garbage is being interpreted
> > as an erroneous connection.
>
> Because you speak HTTP with a server that isn't a HTTP server, right?
>
Yes that is correct. I initally thought that since that data didnt
have the correct bits to be recognized as legitimate it would just be
ignored, but that didn't seem to be the case.

> > I had to create a new option CURLOPT_HTTPPROXYCONNECT without the GET call
> > for my own use.
>
> I find that a bit backwards: first you ask for HTTP and then you disable it.
>
> I rather see this feature as "connect-only", and it isn't even dependent on
> HTTP since HTTP is only used for the CONNECT and you could in fact do this
> same operation to a remove FTP server or similar should you want to.
>
Yes I agree, I was thinking along the same lines too. The HTTP here is
just for the HTTP proxy then it tunnels through that to whatever you
want.

> > I am not sure if the curl community would be interested in VoIP though. It
> > is a transfer too right? Even if it does not involve "concrete" files.
>
> I don't see how your change here is strictly related to VoIP. I would say it
> is more a connect-to-remote-then-stop feature that could be done using
> whatever.
>
> Your ideas seem to be closely related to the work by Vadim Lebedev (who seem
> to have given up or taking a break since his patch updates have stopped
> coming). What do you plan to do when you have made libcurl connect? I trust
> you need to extract the socket and use that somehow since you don't want
> libcurl to do any transfer?
>
Yes, I have actually also already made some changes to extract the
socket and have started on extracting the local port. I am just not
sure though if it will be well-received since it exposes low-level
layers.

> I'm not against the idea of providing this connect-only feature, as I'm not
> againt Vadim Lebedev's socket-extraction either, but I am determined to get
> things like this added in a nice and as clean as possible way.
>
I understand, now I have actually already finished the majority of my
intended changes. So far I have:

1. Connect-only via tunneling on HTTP proxy
 - leaves the socket open, can use any authentication as per curl
(just 5 additional lines of code really, pre-empted the curl_do and
returned success values)

2. Extract the socket
 - I actually contacted Vadim about this. And I used the latest code
that he sent before, with just a few minor changes.

3. Extract the local port
 - about 1/4 finished as of now, any pointers? I'm looking at the
connectdata struct.

All of the above are set via setopt and has the same look and feel as
the ones already in curl.

To round it all up, I think we may also need a transfer (send/receive) function.

> --
> Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
>
Received on 2006-01-13