On Fri, 4 Jan 2008, Dan Fandrich wrote:

> On Sat, Jan 05, 2008 at 01:50:03AM +0100, Richard Atterer wrote:
>> CURLPROXY_SOCKS4
>> CURLPROXY_SOCKS5
>> plus a --socks-hostname/SOCKS_HOSTNAME option, applicable to both v4 and v5
>>
>> IMHO, for compatibility reasons the meaning of CURLPROXY_SOCKS5 should not
>> change. By the way, the following page says that SOCKS 5 "usually uses IP
>> addresses in practice":
>
> This would be my preference. And it might be worthwhile calling it
> --proxy-hostname (or --proxy-resolve), making it usable for HTTP proxies as
> well--I recall that issue coming up before (long before) on this list.

For SOCKS5 that would make perfect sense since the protocol supports it, but
I'm not as sure it is as good for SOCKS4 since then it'll have to change to
the extension protocol SOCKS4A... Also, the option doesn't work for HTTP
proxies atm since we always let the proxy do the resolving there...

But if we're considering such an option, perhaps a SOCKS5_HOSTNAME isn't the
way to go but rather have an option called CURLOPT_PROXY_HOSTNAME that when
set to 1 makes libcurl pass the hostname instead of IP (meaning SOCKS4A, SOCK5
with hostname, HTTP proxy as today) or if set to 0 resolve the name locally
and pass on the IP (meaning SOCKS4, SOCKS5 with IP or HTTP proxy with the host
name resolved and thus an IP sent in the URL).

I get a feeling going CURLOPT_PROXY_HOSTNAME is a bit more complicated than
anyone will ever enjoy. I lean towards plaily making the proxy type
SOCKS5_HOSTNAME supported. (And yes, SOCKS5 is then going back to sending IP
address by default.)

Any further thoughts?

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