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

> 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?

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

> 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?

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.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html