On Fri, Nov 5, 2010 at 9:06 AM, Peter Sylvester <[email protected]> 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: [email protected] 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
