> 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). In both situations curl would have to resolve www.mydomain.com each time and the returned address will depend on the same local resolver, its cache and eventually the servers response. The remaining is just internal substitution.

>> 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.

This would be different with my proposal of some '--alternate-cert-server-name' option, as this will only be used to match the certificate.

-------------------------------------------------------------------
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
Received on 2015-04-23