No, it is not just an engineering issue, which can be solved by changing some easy handle settings in multiple places. No matter how difficult it is (and maybe not always possible) to do it in multiple places, setting IP_RESOLVE option doesn't solve the problem which I am trying to resolve via this proposal.
The "IPv6 works" is checked when a multi handle is created, but before any easy handle is added to it, so it is not related to the IP_RESOLVE option set on any easy handle added to that multi handle later. This is a "system setting" which is checked and set only once when a multi handle is created. The "CURLOPT_USE_SSL, CURLOPT_FOLLOWLOCATION, CURLOPT_USERAGENT or tons of other options" are transfer-specific options managing what some specific transfer would like to use, whereas "IPv6 works" is a system setting, which essentially affects all handles used in the application. So, currently even if IP_RESOLVE is set to IPV4_ONLY for some easy handle, any transfer including transfer doing "easy transfer" via curl_easy_perform() (which creates a multi handle under the hood) will step on this regression when using IPv6-enabled dual stack libcurl vs IPv4 single stack libcurl. The default Curl_ipv6works() is a good default method to detect where IPv6 works or not on the system, but as any default - it is not the best method for ALL possible scenarios. That's why I see the need to provide additional flexibility allowing to detect whether IPv6 works or not in a better way than Curl_ipv6works() does. And again, this issue occurs regardless which IP_RESOLVE setting is used on some easy handle. Thanks, Dmitry Karpov -----Original Message----- From: Dan Fandrich <d...@coneharvesters.com> Sent: Tuesday, September 20, 2022 2:57 PM To: Dmitry Karpov <dkar...@roku.com> Subject: Re: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system On Tue, Sep 20, 2022 at 09:23:35PM +0000, Dmitry Karpov wrote: > That's exactly what I would like to avoid - going through a gazillion places > in numerous components and change something there just to improve how > Curl_ipv6works(). This argument could be made for a hundred other options. Other applications want to set CURLOPT_USE_SSL, CURLOPT_FOLLOWLOCATION, CURLOPT_USERAGENT or tons of other options on every handle, or CURLOPT_FTP_SKIP_PASV_IP, CURLOPT_TCP_KEEPALIVE or CURLOPT_DNS_LOCAL_IP6 based on local network conditions, but none of those make any sense to have set in a callback, either. It sounds to me like the underlying issue isn't really a technical one but rather a software engineering one, which patching libcurl isn't going to solve. Dan -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
