On Thu, 22 Sep 2022, Dmitry Karpov wrote:

If I understand what you suggest, then in all the places where the "AUTO" (CURL_IPRESOLVE_WHATEVER) is used, I would need to use something like:

long resolve_mode = my_ipv6_works() ? CURL_IPRESOLVE_WHATEVER : 
CURL_IPRESOLVE_V4;
curl_easy_setopt(curl, CURLOPT_IPRESOLVE, resolve_mode);

Exactly. Because it would create exactly the same outcome.

First one is that the "AUTO" will stop being the most efficient mode for dual-stack, because its efficiency will depend on how "IPv6 works" check (provided by "factory default" Curl_ipv6works()) works on some systems (kernels, network configs etc).

Not at all. You say you can write a "ipv6works" function (as a callback) that can detect/set the status, so clearly then it can be called by your own application as well. There is no difference in effectiveness between these two approaches. They use the same code to determine IPv6 functionality: your function, and they do it roughly at the same time in the process: right before setting up a new connection.

The only difference is how that function is called.

And if some curl application accidentally steps on this issue and needs to implement some custom "IPv6 works" mechanism, then it is suggested that after implementing it, application developer should go through all the places where transfer options are set, explicitly use application specific "IPv6 works" function and explicitly select IPv4 mode if that function returns "false".

Exactly like you do when you set other properties and control other characteristcs of libcurl transfers. There are *300* options for curl_easy_setopt(), I'm sure you realized by now that this is the libcurl API model.

For some reason you think this particular transfer detail deserves a completely new and different take, and this reason seems to be because of the way you have designed and setup your libcurl usage. In my view, it does not seem to be particularly well founded from a libcurl architectural point of view.

I'm sorry, but I think consistency and simplicity is more important here.

Frankly, I think it is just cruel to make developers do that when everything can be solved in just one system level "IPv6 works" callback.

First: most developers won't write this kind of function at all. curl has supported IPv6 since January 2001 and we are talking about doing this in a future release - after nearly 22 years of shipping IPv6 suppport. Clearly a lot of users manage decently without this.

Then, many users do their setopt logic in a single place or at least offers mechanics to extend the set without going through hoops. Doing this logic as a callback or as a setopt then means roughly the same effort.

I don't think insisting on consistency is cruel.

And for me the biggest problem is that I just can't change the code of certain curl-based components used in my application. They are written by some other developers and closed for any modifications.

This is the core of your issue, not necessarily related to the libcurl issue at hand. I would argue that this is a fragile way to go about libcurl use (and fix). What if you find another flaw tomorrow where a setopt is used wrongly? Would we solve those as well with additional work-arounds and coming in through the backdoor just because someone else has the key to the front door?

In other words, it is much easier and cleaner to override how Curl_ipv6works() to adjust to demands of certain systems/scenarios than do checks if "IPv6 works" and change resolve mode in every place where application sets a transfer.

Easier and cleaner for you. I maintain that it is dirtier for libcurl and its API (design).

Also, Curl_ipv6works() is called only once per multi-handle, and the "IPv6 works" setting is then used for all easy handles added to that multi-handle. So, essentially there is no need to do "IPv6 works" for every easy handle - that's also what the system "IPv6 works" callback efficiently allows to avoid.

When you write your own ipv6works function, you can decide yourself how often and when it needs to rerun the check. There's nothing that says it needs to do anything for every easy handle, it could just return the previous result.

--

 / 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.html

Reply via email to