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: Mon, 26 Sep 2022 22:47:40 +0000
> I could imagine a concept where you create a "system" from which you make easy handles, as then the "system" could define things that all subsequently created easy handles inherit. Like IPv6 functionality.
Exactly. The "system" level is what is needed to customize the "system" behavior for all the handles created in the libcurl application without touching the end client application code (regardless of whether it is opened for modification or not).
The "system" level tweaks will allow to adjust libcurl-based code to run the best possible way for some particular system (HW platform, OS kernel etc) trying to satisfy the "intent" expressed in the transfer setup code as much as possible.
> I think my main problems with your current design proposal is that your "system level" is global (with all the problems and limitations that brings)
> and that it needs to use a callback for information that really isn't needed to be set by a callback.
I think that the fundamental problem I am trying to solve can be expressed as follows:
"How to apply some settings on all handles created by the application (including its integrated components using libcurl) without touching the code that sets them,
because it is not always easy or feasible to change the transfer setting code."
In my particular case, it is "IPv6 works" check which affects how the "resolve mode" option should be applied.
But there may be some other transfer settings that also need some tuning for some particular "system".
I guess such "system" functionality requires using global callbacks with all problems and limitations that it brings for all those adventurous folks who would dare to use that functionality.
And if we look at this problem from a wider perspective, then all settings can be tuned for some system if libcurl provides a just one "system" global callback which can examine and modify all the options set for the transfer before libcurl executes it.
Something like "pre_execute_transfer(CURL* easy_handle, void* data)" (and maybe "pre_execute_multi_transfer(CURLM* multi_handle, void* data) to tune multi-transfers)" .
These callbacks or "hooks", if set, will allow applications to adjust their "system" behavior for a wide range of options - not just for checking if "IPv6 works" without touching end client code (which they might not be able to change).
They will also help to address some security or policy issues when some when integrated components may use some transfer settings which are against some policies enforced in the "hosting" applications.
What do you think about that approach?
It still introduces new global callback(s), but the flexibility that this approach brings in allows to do a wide range of "system" customizations beyond just IPv6.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Monday, September 26, 2022 2:52 PM
To: Dmitry Karpov <dkarpov_at_roku.com>
Cc: Dmitry Karpov via curl-library <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 Mon, 26 Sep 2022, Dmitry Karpov wrote:
> Your proposal for fixing problem with the default "IPv6 works"
> function is to move the problem from the "system" level to the
> "client" level and make clients aware of which "platform" (HW, kernel
> version etc) they may running on and use platform-specific "IPv6
> works" function in all places where transfer is set.
I think your idea of two separate levels, system and client, is interesting, and it could be worth exploring.
I could imagine a concept where you create a "system" from which you make easy handles, as then the "system" could define things that all subsequently created easy handles inherit. Like IPv6 functionality.
system = curl_system_init();
easy = curl_easy_init_system(system);
which possibly could be faked pretty good today with:
system = curl_easy_init()
easy = curl_easy_duphandle(system);
an alernative could be to (somehow) store easy options for a specified scope within a multi handle, so when you create new easy handles for use in a certain multi handle you could:
easy = curl_easy_inherit(multi);
I think my main problems with your current design proposal is that your "system level" is global (with all the problems and limitations that brings) and that it needs to use a callback for information that really isn't needed to be set by a callback. Details that are the direct results of your introduciton of these separated levels without libcurl actually having any such separation of priviledges and now you have to shoehorn them in and then it can't be done in a very clean way.
> And if documenting, publishing etc is a hassle then can we make it
> "undocumented API" then?
No, that's just worse. We either have an API or we do not. If we have it, we support it completely and it needs to be fully documented so that everyone knows what to expect from it, and it needs to be tested. Otherwise it will lead to security problems and that we accidentally slightly break behavior in a future with the following sad faces.
Every function we add has a weight and a cost. It adds code, it adds docs, it adds tests and it adds to the haystack for people trying to find their needles. It is our duty to always resist adding more. Until we are convinced we need to add the new stuff.
Date: Mon, 26 Sep 2022 22:47:40 +0000
> I could imagine a concept where you create a "system" from which you make easy handles, as then the "system" could define things that all subsequently created easy handles inherit. Like IPv6 functionality.
Exactly. The "system" level is what is needed to customize the "system" behavior for all the handles created in the libcurl application without touching the end client application code (regardless of whether it is opened for modification or not).
The "system" level tweaks will allow to adjust libcurl-based code to run the best possible way for some particular system (HW platform, OS kernel etc) trying to satisfy the "intent" expressed in the transfer setup code as much as possible.
> I think my main problems with your current design proposal is that your "system level" is global (with all the problems and limitations that brings)
> and that it needs to use a callback for information that really isn't needed to be set by a callback.
I think that the fundamental problem I am trying to solve can be expressed as follows:
"How to apply some settings on all handles created by the application (including its integrated components using libcurl) without touching the code that sets them,
because it is not always easy or feasible to change the transfer setting code."
In my particular case, it is "IPv6 works" check which affects how the "resolve mode" option should be applied.
But there may be some other transfer settings that also need some tuning for some particular "system".
I guess such "system" functionality requires using global callbacks with all problems and limitations that it brings for all those adventurous folks who would dare to use that functionality.
And if we look at this problem from a wider perspective, then all settings can be tuned for some system if libcurl provides a just one "system" global callback which can examine and modify all the options set for the transfer before libcurl executes it.
Something like "pre_execute_transfer(CURL* easy_handle, void* data)" (and maybe "pre_execute_multi_transfer(CURLM* multi_handle, void* data) to tune multi-transfers)" .
These callbacks or "hooks", if set, will allow applications to adjust their "system" behavior for a wide range of options - not just for checking if "IPv6 works" without touching end client code (which they might not be able to change).
They will also help to address some security or policy issues when some when integrated components may use some transfer settings which are against some policies enforced in the "hosting" applications.
What do you think about that approach?
It still introduces new global callback(s), but the flexibility that this approach brings in allows to do a wide range of "system" customizations beyond just IPv6.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Monday, September 26, 2022 2:52 PM
To: Dmitry Karpov <dkarpov_at_roku.com>
Cc: Dmitry Karpov via curl-library <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 Mon, 26 Sep 2022, Dmitry Karpov wrote:
> Your proposal for fixing problem with the default "IPv6 works"
> function is to move the problem from the "system" level to the
> "client" level and make clients aware of which "platform" (HW, kernel
> version etc) they may running on and use platform-specific "IPv6
> works" function in all places where transfer is set.
I think your idea of two separate levels, system and client, is interesting, and it could be worth exploring.
I could imagine a concept where you create a "system" from which you make easy handles, as then the "system" could define things that all subsequently created easy handles inherit. Like IPv6 functionality.
system = curl_system_init();
easy = curl_easy_init_system(system);
which possibly could be faked pretty good today with:
system = curl_easy_init()
easy = curl_easy_duphandle(system);
an alernative could be to (somehow) store easy options for a specified scope within a multi handle, so when you create new easy handles for use in a certain multi handle you could:
easy = curl_easy_inherit(multi);
I think my main problems with your current design proposal is that your "system level" is global (with all the problems and limitations that brings) and that it needs to use a callback for information that really isn't needed to be set by a callback. Details that are the direct results of your introduciton of these separated levels without libcurl actually having any such separation of priviledges and now you have to shoehorn them in and then it can't be done in a very clean way.
> And if documenting, publishing etc is a hassle then can we make it
> "undocumented API" then?
No, that's just worse. We either have an API or we do not. If we have it, we support it completely and it needs to be fully documented so that everyone knows what to expect from it, and it needs to be tested. Otherwise it will lead to security problems and that we accidentally slightly break behavior in a future with the following sad faces.
Every function we add has a weight and a cost. It adds code, it adds docs, it adds tests and it adds to the haystack for people trying to find their needles. It is our duty to always resist adding more. Until we are convinced we need to add the new stuff.
-- / 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-27