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: Daniel Gustafsson via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 20 Apr 2022 10:34:33 +0200
> On 20 Apr 2022, at 02:27, Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se> wrote:
>> Note that for some resolvers, it may be necessary to back translate their response code to the DNS RFCs'. But that work ends up in curllib, not in the application.
>
> Assuming that it would be always possible to translate back resolver-specific codes into some general "DNS codes" (although it might be not always the case), such translation logic will create a dependency on the resolver.
> So, whenever the resolver add/modify/remove its internal codes in a new version, libcurl will have to update the translation layer (if it is implemented there) to keep it up to date.
> And for multiple resolvers, it will be a maintenance mess.
>
> On the other hand, the application knows which resolver (and which specific version) it uses, so it can update the translation layer (code-to-text, if it needs it) once it updates the resolver version.
>
> Returning an opaque resolver code in case of host resolution failures is enough debug information for application developers to build application-specific resolver translation layers, which will be aligned with resolver versions their application is using (i.e. specific version of c-ares etc).
This will push the "maintenance mess" on to applications using libcurl, with
the vast majority of them having no idea about (or interest in) which resolver
is used. And what if we add a new resolver, do all libcurl using applications
need to update?
We already provide abstracted error codes for subsystems which support multiple
backends, like TLS and QUIC etc, I don't see why this would be any different.
Additional backend specific metadata is passed with failf() calls.
Date: Wed, 20 Apr 2022 10:34:33 +0200
> On 20 Apr 2022, at 02:27, Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se> wrote:
>> Note that for some resolvers, it may be necessary to back translate their response code to the DNS RFCs'. But that work ends up in curllib, not in the application.
>
> Assuming that it would be always possible to translate back resolver-specific codes into some general "DNS codes" (although it might be not always the case), such translation logic will create a dependency on the resolver.
> So, whenever the resolver add/modify/remove its internal codes in a new version, libcurl will have to update the translation layer (if it is implemented there) to keep it up to date.
> And for multiple resolvers, it will be a maintenance mess.
>
> On the other hand, the application knows which resolver (and which specific version) it uses, so it can update the translation layer (code-to-text, if it needs it) once it updates the resolver version.
>
> Returning an opaque resolver code in case of host resolution failures is enough debug information for application developers to build application-specific resolver translation layers, which will be aligned with resolver versions their application is using (i.e. specific version of c-ares etc).
This will push the "maintenance mess" on to applications using libcurl, with
the vast majority of them having no idea about (or interest in) which resolver
is used. And what if we add a new resolver, do all libcurl using applications
need to update?
We already provide abstracted error codes for subsystems which support multiple
backends, like TLS and QUIC etc, I don't see why this would be any different.
Additional backend specific metadata is passed with failf() calls.
-- Daniel Gustafsson https://vmware.com/ -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-04-20