On 6/28/2016 6:13 PM, Richard Gray wrote:
However, I am curious as to why libcurl doesn't just refuse to attempt
the operation instead of crashing in curl_multi_perform().
I got into this because up till now, the application has only been
doing simple HTTP. I recently updated to a build which had SSL
support (libcurl/7.47.0 WinSSL WinIDN) and I hit a device which
redirected from HTTP to HTTPS. So I hadn't really configured for
HTTPS - I was just starting to allow redirects to be followed.
I know that an automatic curl_global_init() happens on the first
curl_easy_setopt() if one has not previously called
curl_global_init(). Does SSL auto-initialize late too if not done via
curl_global_init()?? (Our program has already gone multi-threaded at
this point.) I don't see anything in the documentation pages for
curl_global_init() or libcurl that suggest a danger from late SSL
auto-initialization or not explicitly initializing. Or could this be
a legitimate error condition that should be caught?
I see that, somehow, I've also been skating without the
CURL_GLOBAL_WIN32 bit. Hasn't hurt me (yet!), but I'm now using
CURL_GLOBAL_DEFAULT.
In the rare circumstance where you do your own Winsock and/or SSL
initialization you may be able to skip using CURL_GLOBAL_WIN32 and/or
CURL_GLOBAL_SSL. It's not recommended or documented how to do that
safely in a way that meets libcurl's requirements of those libraries,
which may change. If you explicitly initialize libcurl without using
those flags then behavior is undefined. For example if libcurl doesn't
use SSL and Winsock implicitly initializes itself then you may get away
with it, but it's still undefined.
Specifically in the case of WinSSL initialization, IIRC there's no way
to properly initialize it on your own without CURL_GLOBAL_SSL. For other
backends that may not be true, like OpenSSL. That is subject to change,
but probably won't given the init conflicts some developers have had
with OpenSSL. Ideally you call curl_global_init at least once at the
very beginning of your program with CURL_GLOBAL_DEFAULT, before anything
else that could initialize the SSL library used by libcurl, and all the
other documented requirements.
There is an implicit global init but it's in curl_easy_perform, not
curl_easy_setopt, and it sets CURL_GLOBAL_DEFAULT [1]. If you rely on
that (not recommended) you would still have to heed the requirements of
curl_global_init the first time you call curl_easy_perform. Most
notably, it's not thread safe.
Also I notice you are using libcurl 7.47 in Windows. If you are also
using the curl tool 7.47.0 there was a bug in the output sanitization
for Windows where I over-sanitized (eg c:\foo path was changed to
c__foo) and that was fixed in 7.47.1. There is also a cert advisory with
a fix in 7.49.1 for DLL hijacking (low impact if your OS is recent). I
would use the latest release, if you can. There are a bunch of other
fixes since 7.47 [2].
[1]: https://github.com/curl/curl/blob/curl-7_49_1/lib/easy.c#L373-L381
[2]: https://curl.haxx.se/changes.html
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
