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: Feature request about curlinfo option returning resolver status/error code
- 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, 2 May 2022 19:15:29 +0000
> 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 <daniel_at_yesql.se>
Sent: Saturday, April 30, 2022 12:49 PM
To: libcurl development <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>; Daniel Stenberg <daniel_at_haxx.se>
Subject: Re: Feature request about curlinfo option returning resolver status/error code
> On 30 Apr 2022, at 12:42, Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se> 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.
Date: Mon, 2 May 2022 19:15:29 +0000
> 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 <daniel_at_yesql.se>
Sent: Saturday, April 30, 2022 12:49 PM
To: libcurl development <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>; Daniel Stenberg <daniel_at_haxx.se>
Subject: Re: Feature request about curlinfo option returning resolver status/error code
> On 30 Apr 2022, at 12:42, Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se> 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.htmlReceived on 2022-05-02