On Fri, Nov 5, 2010 at 9:06 AM, Peter Sylvester
<peter.sylvester_at_edelweb.fr> wrote:
>  let's take a strawman like
>
>   --proxy  ip-address --proxyport 0  or DIRECT or another parm.
>
> or
>   --resolve  host.example.com:ipaddress
>
> and an url  https://host.example.com
>
>> Furthermore, requiring a proxy like this prevents me from solving use case
>> 2.
>
> there is not application level proxy.
>
>  curl --proxy 127.0.0.1 --proxyport 0 https://jgjgj
>
> in the DEBUG_BUILD you can use for example
>
>  curl --interface LocalHost https://some.host.exmple.com
>
> and without any actual DNS resolution of some....
>
> "localhost" ist used instead. here is the actual code in hostip.c
>
>    addr = Curl_getaddrinfo(conn,
> #ifdef DEBUGBUILD
>                            (data->set.str[STRING_DEVICE]
> && !strcmp(data->set.str[STRING_DEVICE],
>                                        "LocalHost"))?"localhost":
> #endif
>                            hostname, port, &respwait);
>
> wouldn't a code like
>
>    if  (proxy is set and an and proxyport is 0)
>         resolve the proxy instead of the hostname
>
> would solve your requirements?
>
>>
>>> Another way of looking would be to "resolve" the host
>>> part in a different way, i.e. not passing thru a dns lookup.
>>> like by changing a local /etc/hosts.
>>
>> That would require the user of my app to change his system
>> configuration, which I consider an unnecessary step that the user
>> shouldn't have to bother with.
>
> i want to say "another way of looking at the problem is to
> think about it as a host name resolve problem".  i.e. to
> find a solution which is equivalent of setting etc/hosts
>
> I find it unnecessary to require a user to run an
> operating system. curl should do everything ;-)
>
> you say that setting an etc host for option 2 would be ok
> but inconvenient, thus, a parameter
>
> curl  --resolve hostname:address   https://hostname
>
> which, by avoiding a new parameter could be done
> by overloading the proxy by
>
> curl  --proxy  address --proxyport 0  https://hostname
>
> or something like that.
>>
>> Furthermore, this proposal would solve
>> neither use case 1 nor use case 2.
>
> hm, why not?  I think I wasn't sufficiently clear.

I think that what you're saying is that you want to use --proxy as
some kind of mechanism to override normal DNS resolution. That sounds
good, but I'm not sure --proxy is the right option for that, I think
it's confusing because this really isn't about proxy but about DNS
resolution.

I like the --resolve option. It does look like the cleanest way to
solve this problem (including certificate matching) is to add a
feature to Curl to override DNS resolution for a specified list of
domains, kind of like an in-process /etc/hosts alternative.

-- 
Phusion | The Computer Science Company
Web: http://www.phusion.nl/
E-mail: info_at_phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html