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 <[email protected]> Sent: Tuesday, April 19, 2022 11:49 AM To: libcurl development <[email protected]> Cc: Daniel Stenberg <[email protected]>; Dmitry Karpov <[email protected]> Subject: Re: Feature request about curlinfo option returning resolver status/error code > On 19 Apr 2022, at 19:35, Dmitry Karpov via curl-library > <[email protected]> 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.html
