On 9/25/22 10:30, Daniel Stenberg wrote:
On Sun, 25 Sep 2022, Patrick Monnerat wrote:
main()
{
const curl_version_info_data *vid;
vid = curl_version_info(CURLVERSION_NOW);
printf("%08X\n", vid->features);
curl_global_sslset(CURLSSLBACKEND_OPENSSL, NULL, NULL);
curl_version_info(CURLVERSION_NOW);
printf("%08X\n", vid->features);
}
Result (with a MultiSSL library):
75DFE7DD
75FFE7DD
Right, but I would argue this is not using the API as documented and
intended. The global init call should be called before
curl_version_info() if you want it to return a "stable" value.
This can introduce a chicken-and-egg-like problem:
- curl_version_info() has to be called to know multiSSL is featured
- curl_global_sslset() must be called before curl_global_init()
- from your statement above, curl_version_info() has to be called again
after curl_global_init()
I don't see any incompatibility with the documentation. The sequence
above probably won't hurt most programs, but is not threadsafe.
The problem is: HTTPS-proxy is not really a libcurl feature with
multiSSL, rather an SSL backend feature. Curl features were not
initially designed to be dynamic but more of a curl initial
configuration state.
IMO, features can be detemined at run-time (like it is done for IDN),
but the result should not change over time.
I see only 2 solutions to this:
1) Consider multiSSL as a backend on its own that do not support
HTTPS-proxy. Even after setting the real backend.
2) Document curl_version_info() as not threadsafe until
curl_global_init() is called.
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
