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

Well yes and no.

First of all --resolve currently only supports one single address as far as I
understand the code (even if you put in multiple --resolve for the same name),
so adding the FQDN support would only keep that limitation.

So if we have:

 1) --resolve hoster.com:80:<mydomain.com address> http://hoster.com/
 2) -- resolve hoster.com:80:mydomain.com http://hoster.com/
 3) http://mydomain.com

So if one uses --resolve he only gets one address (cases 1 & 2), whereas without (case 3)
the resolver would potentially get multiple addresses through getaddrinfo.

As to my understanding the change would go into Curl_loadhostpairs which actually parses
the list of --resolve entries. First of all the name may not be correct anymore :-)

The easiest way would be to simply resolve the entry and take the first returned address
Keeping the single address limitation. But one could also call the curl resolver from here
and use the returned structures to build the cache entry.

I don't see that this would have a major impact on the code as everything is ther already.
But of course, you are the expert, and I may simply oversee something !

One could even go forward and remove the single address limitation also for addresses by
allowing something like --resolve <name>:<port>:<address-or-fqdn1>[,<address-or-fqdn2>,...]
which I think would be more complicated than the multi-address fqdn support

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

Sorry, I don't get this. I am speaking of virtual hhtp servers identified
Through the used servername in the HTTP 1.1 request. I.e. if several virtual
servers name1.mydomain.com, name2.mydomain.com share the same IP address.

If my site is name2.mydomain.com but the hoster only returns certificate
for hoster.com and I want to have certificate validation, I will have to use

--resolve hoster.com:<port>:<address> http://hoster.com/

This will successfully match the certificate but will send hoster.com as server
inside the request, thus the virtual server could not be mapped at server side.
 
> > 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.
>

Partially yes, but I think not completely (as stated above). But I may wrong.

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