On Tue, 10 Aug 2010, Matthieu Speder wrote:
We could (or should?) perhaps do the same when a custom Host: is used and
an SNI name is passed on, as then (lib)curl would still do the proper SNI
even when trying out a local https:// site like above.
Agree. And by the way I think that this might be the right thing to do
anyway, even without my strange context. The only restriction I see is that
HTTP header is only relevant for HTTP service while TLS SNI could in theory
apply to non HTTP also. However, in real life, I'm not aware of any TLS
server really using SNI apart from HTTPS servers.
Right. And for other protocols, there need to be a similar header/command
(like HOST is being suggested for FTP) that then would get the same treatment
by us!
I looked for a way to implement your idea. Main issue is that today
cookiehost if filled only after the TLS session is built. I did a quick test
looking in the header directly and it worked perfectly (see sample code
below). However it looks like we do the job of looking in the header twice,
so maybe you would do it a different way ?
I would rather have the code extract and store the "Host:" header name in a
single place and use it for both features.
sniname = ptr?Curl_copy_header_value(ptr):NULL;
if (!sniname &&
A failure to allocate memory (which a NULL pointer means here) is a serious
error and MUST result in a clean bailout with an error code.
(0 == Curl_inet_pton(AF_INET,
conn->host.name, &addr)) #ifdef ENABLE_IPV6
&& (0 == Curl_inet_pton(AF_INET6,
conn->host.name, &addr)) #endif
) {
Can the SNI field really not be set to work with an IP address? What if you
have multiple IP addresses, have the server listen on all of them and connect
to the host using https://1.2.3.4/moo ?
The cookie engine at least will need the Host: name as '1.2.3.4' in that case.
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
