hi,

On 11/04/2010 11:35 PM, Hongli Lai wrote:
> On Thu, Nov 4, 2010 at 11:19 PM, Peter Sylvester
> <peter.sylvester_at_edelweb.fr> wrote:
>> hello,
>>
>> soory for the top post, but I am not directly
>> replying to any particular message.
>>
>> I am not really convinced that the approach using a
>> Host header to derive the sni is a good way.
>>
>> IMO a Host header is something that should be derived
>> from the URL host part, as well as a SNI, and not
>> in the other way around.
>>
>> If one wants to connect to a particular IP address
>> in order to go to https://some.domain/ then the
>> problem could be regarded as a "proxy issue",
>> instead of a proxy that uses CONNECT, one could
>> invent a direct/immediate proxy type.
>> So instead of resolving the DNS for a direct connection,
>> one would use connect to this "proxy".
> That would require me to setup a proxy server, and for what gain? Just
> to make an HTTP library do what I want?
  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.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-11-05