hi,
On 11/04/2010 11:35 PM, Hongli Lai wrote:
On Thu, Nov 4, 2010 at 11:19 PM, Peter Sylvester
<[email protected]> 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
