Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
RE: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 29 Sep 2022 19:18:57 +0000
> I still don't like the idea of having a "global" system level. We can easily think of a system where you run stuff multi-threaded, and then you might want one "system" for each thread's app level.
But this I guess what application can relatively easy provide.
For instance, some global "system" callback implementation may access application-specific thread local contexts or use other thread synchronization mechanisms specific to that application.
I guess libcurl should only provide a thread-safe mechanism to set "system" callbacks for apps that want to use them, and problems with invoking those callbacks in multiple threads should be application concern.
> I also like the thought that this would have to be explicit and not implicit:
> meaning that the app would have to agree to and opt-in being overrided by a
> (specific) system level. Possibly by a CURLOPT_SYSTEM=[system handle] option, possibly by having a new curl_easy_init() version that takes the [system handle] as an argument.
Sure, it has to be explicit "opt-in" mechanism.
But the most important feature of such mechanism is that it should allow applications providing "hosting system" for other components using libcurl (which may be closed for modification) to be able to tune
(or even limit) their behavior when they are running in the "hosting" environment.
So, this mechanism should specify the behavior of the libcurl "system", which should be allowed to be initialized only once - by the "hosting" application,
and any secondary "system" tuning calls from the "hosted" components will be ignored to avoid system "hacking".
I thought that "struct curl_system_funcs" with curl_global_init_system() could be used for creating a "system", but may be instead we can add a new handle type
- "system handle", as you called it, and have a set of "system options".
Something like "CURLS" or "CURLSYS" handle type for "system option" (in addition to "easy", "multi", "share" and "url" types ) and provide "curl_system_init()", " curl_share_setopt()" etc.
The "system" handle will represent a structure similar to curl_system_funcs exposing its members via "system" options rather than via direct member access.
I guess "CURLOPT_SYSTEM=[system handle]" in your comment matches that idea.
But in order this to work for "hosting" systems, we will probably still need some global "pre-transfer" callback, which will allow to set CURLOPT_SYSTEM option early on,
before upper client code can set any options and thus override it.
> If we would do this with callbacks, then maybe there should be a system callback for any option the app sets.
> To allow the system to filter or alter what is actually set in the app handle.
That would be great! We can probably have such "on_option_set" filter function as one of the options of the "system" handle.
I guess a combination of a "system" handle and "pre-transfer" global callback is a good alternative to "curl_system_funcs/ curl_global_init_system()" approach for "system" layer implementation.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Thursday, September 29, 2022 12:09 AM
To: Dmitry Karpov <dkarpov_at_roku.com>
Cc: libcurl development <curl-library_at_lists.haxx.se>
Subject: RE: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system
On Tue, 27 Sep 2022, Dmitry Karpov wrote:
> So, for tuning just a few "system" settings, I am thinking that maybe
> we can have something like:
>
> curl_global_init_system(long flags, curl_system_funcs *system_funcs);
I still don't like the idea of having a "global" system level. We can easily think of a system where you run stuff multi-threaded, and then you might want one "system" for each thread's app level.
I also like the thought that this would have to be explicit and not implicit:
meaning that the app would have to agree to and opt-in being overrided by a
(specific) system level. Possibly by a CURLOPT_SYSTEM=[system handle] option, possibly by having a new curl_easy_init() version that takes the [system handle] as an argument.
> struct curl_system_funcs {
> curl_ipv6works ipv6_works; // Function checking if IPv6 works on
> the system
If we would do this with callbacks, then maybe there should be a system callback for any option the app sets. To allow the system to filter or alter what is actually set in the app handle.
Date: Thu, 29 Sep 2022 19:18:57 +0000
> I still don't like the idea of having a "global" system level. We can easily think of a system where you run stuff multi-threaded, and then you might want one "system" for each thread's app level.
But this I guess what application can relatively easy provide.
For instance, some global "system" callback implementation may access application-specific thread local contexts or use other thread synchronization mechanisms specific to that application.
I guess libcurl should only provide a thread-safe mechanism to set "system" callbacks for apps that want to use them, and problems with invoking those callbacks in multiple threads should be application concern.
> I also like the thought that this would have to be explicit and not implicit:
> meaning that the app would have to agree to and opt-in being overrided by a
> (specific) system level. Possibly by a CURLOPT_SYSTEM=[system handle] option, possibly by having a new curl_easy_init() version that takes the [system handle] as an argument.
Sure, it has to be explicit "opt-in" mechanism.
But the most important feature of such mechanism is that it should allow applications providing "hosting system" for other components using libcurl (which may be closed for modification) to be able to tune
(or even limit) their behavior when they are running in the "hosting" environment.
So, this mechanism should specify the behavior of the libcurl "system", which should be allowed to be initialized only once - by the "hosting" application,
and any secondary "system" tuning calls from the "hosted" components will be ignored to avoid system "hacking".
I thought that "struct curl_system_funcs" with curl_global_init_system() could be used for creating a "system", but may be instead we can add a new handle type
- "system handle", as you called it, and have a set of "system options".
Something like "CURLS" or "CURLSYS" handle type for "system option" (in addition to "easy", "multi", "share" and "url" types ) and provide "curl_system_init()", " curl_share_setopt()" etc.
The "system" handle will represent a structure similar to curl_system_funcs exposing its members via "system" options rather than via direct member access.
I guess "CURLOPT_SYSTEM=[system handle]" in your comment matches that idea.
But in order this to work for "hosting" systems, we will probably still need some global "pre-transfer" callback, which will allow to set CURLOPT_SYSTEM option early on,
before upper client code can set any options and thus override it.
> If we would do this with callbacks, then maybe there should be a system callback for any option the app sets.
> To allow the system to filter or alter what is actually set in the app handle.
That would be great! We can probably have such "on_option_set" filter function as one of the options of the "system" handle.
I guess a combination of a "system" handle and "pre-transfer" global callback is a good alternative to "curl_system_funcs/ curl_global_init_system()" approach for "system" layer implementation.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Thursday, September 29, 2022 12:09 AM
To: Dmitry Karpov <dkarpov_at_roku.com>
Cc: libcurl development <curl-library_at_lists.haxx.se>
Subject: RE: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system
On Tue, 27 Sep 2022, Dmitry Karpov wrote:
> So, for tuning just a few "system" settings, I am thinking that maybe
> we can have something like:
>
> curl_global_init_system(long flags, curl_system_funcs *system_funcs);
I still don't like the idea of having a "global" system level. We can easily think of a system where you run stuff multi-threaded, and then you might want one "system" for each thread's app level.
I also like the thought that this would have to be explicit and not implicit:
meaning that the app would have to agree to and opt-in being overrided by a
(specific) system level. Possibly by a CURLOPT_SYSTEM=[system handle] option, possibly by having a new curl_easy_init() version that takes the [system handle] as an argument.
> struct curl_system_funcs {
> curl_ipv6works ipv6_works; // Function checking if IPv6 works on
> the system
If we would do this with callbacks, then maybe there should be a system callback for any option the app sets. To allow the system to filter or alter what is actually set in the app handle.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-29