> Shouldn't that value then rather just get shown with an infof() call? > Yes, a backend agnostic error code with the backend specific information > added with infof(). This is what we do for other variable-backend subsystems > and I don't see why this would benefit from being different.
The infof() call creates a debug output, which may be not enabled when the problem occurs, especially on embedded systems where debugging output may create performance or log storage issues and thus disabled. And even if it is possible to enable it by demand, it may be too late to catch a problem if it is intermittent. In such cases, it is much simpler and helpful to get a resolver code via the curl_info mechanism when DNS issue occurs and log it exactly when the error has occurred. It will also allow precisely identify the DNS error code with the failed transfer, which is helpful with many transfers performed in parallel. And it is already mentioned, there are many cases when resolver errors are truly resolver/OS specific, which are not easy to map into some generic DNS mappings. Besides, there is already a CURLOPT_RESOLVER_START_FUNCTION option which provides a similar functionality - points to a backend-specific resolver state, and currently only the ares resolver backend has a resolver state. This option provides access to "opaque" resolver state (which currently only c-ares has). And the proposed CURLINFO_RESOLVER_CODE info option, which returns "opaque" resolver code, seems to be a logical completion of the first option. Both these options are useful in advanced scenarios, where application needs to fine-tune and debug some specific resolver. Thanks, Dmitry Karpov -----Original Message----- From: Daniel Gustafsson <[email protected]> Sent: Saturday, April 30, 2022 12:49 PM To: libcurl development <[email protected]> Cc: Dmitry Karpov <[email protected]>; Daniel Stenberg <[email protected]> Subject: Re: Feature request about curlinfo option returning resolver status/error code > On 30 Apr 2022, at 12:42, Daniel Stenberg via curl-library > <[email protected]> wrote: > > On Mon, 25 Apr 2022, Dmitry Karpov wrote: > >> So, as far as documentation is concerned, I was envisioning that this >> feature will be documented as "opaque resolver code, which meaning depends >> on the used resolver backend". Because this is a debugging feature, there is >> no need to document more in libcurl, and the application developers can look >> it up in the resolver code and provide a better information/description if >> needed. > > Shouldn't that value then rather just get shown with an infof() call? Yes, a backend agnostic error code with the backend specific information added with infof(). This is what we do for other variable-backend subsystems and I don't see why this would benefit from being different. -- Daniel Gustafsson https://vmware.com/ -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
