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: Tue, 19 Apr 2022 19:18:35 +0000
The resolvers can have completely different codes, and some of them maybe completely resolver-specific (or resolvers may not provide any status codes at all).
The CURLINFO_RESOLVER_CODE would help to debug issues with some specific resolver, so I am not sure if it will be very beneficial to create some abstract resolver codes here .
It would be much better, in my opinion, to return resolver codes "as is" rather than mapping them into some abstract values.
For instance, it will help to debug some internal resolver errors, which may be reported via resolver status codes but don't have good abstract translation.
-----Original Message-----
From: Daniel Gustafsson <daniel_at_yesql.se>
Sent: Tuesday, April 19, 2022 11:49 AM
To: libcurl development <curl-library_at_lists.haxx.se>
Cc: Daniel Stenberg <daniel_at_haxx.se>; Dmitry Karpov <dkarpov_at_roku.com>
Subject: Re: Feature request about curlinfo option returning resolver status/error code
> On 19 Apr 2022, at 19:35, Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se> wrote:
>
> It would return a status code the resolver returns when it performs a DNS query.
>
> For instance, c-ares passes its status code in resolution callbacks, so this status code would be returned in the CURLINFO_RESOLVER_CODE.
> So, if something goes wrong with host name resolution, this code will give a hint why the resolver failed.
If we are returning a code it should be an abstracted/translated code which doesn't rely on a specific resolver (ie the set of returncodes should not change depending on the resolver).
This is clearly not hard to do, but we need to figure out a good mapping.
Date: Tue, 19 Apr 2022 19:18:35 +0000
The resolvers can have completely different codes, and some of them maybe completely resolver-specific (or resolvers may not provide any status codes at all).
The CURLINFO_RESOLVER_CODE would help to debug issues with some specific resolver, so I am not sure if it will be very beneficial to create some abstract resolver codes here .
It would be much better, in my opinion, to return resolver codes "as is" rather than mapping them into some abstract values.
For instance, it will help to debug some internal resolver errors, which may be reported via resolver status codes but don't have good abstract translation.
-----Original Message-----
From: Daniel Gustafsson <daniel_at_yesql.se>
Sent: Tuesday, April 19, 2022 11:49 AM
To: libcurl development <curl-library_at_lists.haxx.se>
Cc: Daniel Stenberg <daniel_at_haxx.se>; Dmitry Karpov <dkarpov_at_roku.com>
Subject: Re: Feature request about curlinfo option returning resolver status/error code
> On 19 Apr 2022, at 19:35, Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se> wrote:
>
> It would return a status code the resolver returns when it performs a DNS query.
>
> For instance, c-ares passes its status code in resolution callbacks, so this status code would be returned in the CURLINFO_RESOLVER_CODE.
> So, if something goes wrong with host name resolution, this code will give a hint why the resolver failed.
If we are returning a code it should be an abstracted/translated code which doesn't rely on a specific resolver (ie the set of returncodes should not change depending on the resolver).
This is clearly not hard to do, but we need to figure out a good mapping.
-- Daniel Gustafsson https://vmware.com/ -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-04-19