On Tue, 29 Jan 2013, Guenter wrote:

> The example.[com|edu|net|org] domains are now redirected to
> http://www.iana.org/domains/example
> which make some of our example codes no longer working unchanged;

Well, they still worked. They just got a slightly less interesting response.

> unfortunately https connections cant be fixed this way:

Right, clearly there's no service on port 443 there.

> BTW. while testing this I found that the returned error 60 above seems wrong
> or at least misleading because this is a registered certificate:
> curl -v --cacert ca-bundle.crt https://www.iana.org/domains/example

"registered" perhaps, but not signed with a CA that's in your default ca cert
bundle...

> or is it normal that without a ca-bundle.crt all SSL certs are assumed to be
> self signed?

Yes. The only way we can know if a cert is signed by a trusted CA is by having
that trusted CA's cert in our bundle. A typical curl build will however find
and use a default ca bundle to use.

> I would like to change the URL in https.c to
> https://www.iana.org/domains/example
> - any objections?

I object! We switched to example.(org|net|com) all over the examples and
documentation exactly because they are documented domains for exactly this
purpose - see RFC2606. Their names also very clearly highlights that they are
examples so if someone wants to run the code against something "real" then I
think they should change the URL themselves.

*If* we would change the URLs in any example or docs (which I obviously don't
think we should), I would then rather point out a host name a long-term
regular in the curl project owns/admins so that we can get a higher confidence
of functionality and awareness of what gets returned...

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html