On Thu, 23 Apr 2015, Gaston Gloesener wrote:

>> A FQDN is however potentially a large amount of IP addresses and they could
>> even change over time, so it would require quite a lot more than just a
>> simple initial DNS resolve to make right.
>
> Why would that matter ? Using --resolve www.hoster.com:80:www.mydomain.com
> with url http://www.hoster.com/ should behave exactly like
> http://www.mydomain.com/ would (in regard of the IP address).

That's exactly my point. The current --resolve functionality is a lot simpler
than so, so if you want to support a FQDN instead of a single fixed IP we need
to implement code to support that. It is (much) more than just replacing the
name with a single numerical IP.

>>> Another point is that --resolve will not work with HTTP 1.1 name based
>>> virtual hosts.

>> Why not?
>
> Because in my example my virtual server would be somename.mydomain.com but
> the unchangeable certificate be for *.hoster.com . So I will have to use
> --resolve somename.hoster.com:80:somename.mydomain.com
> http://somename.hoster.com/ . With this request I would expect curl to send
> somename.hoster.com as server name, not the expected somename.mydomain.com.

You'd use it in a style similar to --resolve mydomain.com:443:127.0.0.1

... then https://mydomain.com/ will go to your custom site. SNI, virtual hosts
and everything work then.

> This would be different with my proposal of some
> '--alternate-cert-server-name' option

Yes it is different, but you can probably achieve what you want with the
existing funtionality.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ:        http://curl.haxx.se/docs/faq.html
Etiquette:  http://curl.haxx.se/mail/etiquette.html