Re: curl_version_info() thread-safety

From: Patrick Monnerat via curl-library <curl-library_at_lists.haxx.se>
Date: Sun, 25 Sep 2022 13:01:17 +0200

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

Received on 2022-09-25