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: Fri, 22 Apr 2022 19:26:57 +0000
This would make a perfect sense if all resolvers provided most of their codes very close to general DNS RCODEs with a very small resolver-specific set "Reserved for Private Use".
But this is not the case, as far as I can tell, and the resolvers never intended to return status codes close to DNS RCODEs.
The getaddrinfo() error codes are very resolver-specific, and on Windows there is also an OS-specific subset of errors obtained via WSAGetLastError().
So, most of the codes returned by the resolvers will be "Reserved for Private Use", with a very tiny subset from some specific resolvers that can be probably mapped into common DNS RCODEs.
This makes creating and maintaining such mapping not very useful.
And any changes in some resolver status codes will require changes in libcurl to maintain the mapping up to date.
For many different libcurl+resolver combinations it will become a maintenance problem very soon.
When I proposed the CURLINFO_RESOLVER_CODE info option, the main purpose was to help developers to debug resolver-specific issues, when something goes wrong and “opaque” resolver code in case of errors would be a good hint (regardless of whether it is a common DNS problem or some internal resolver issue).
From that perspective, any mapping hiding the resolver code will require additional operation from the developer to do “unmapping” in libcurl first to get to the actual resolver code.
So, a very simple info option, like CURLINFO_RESOLVER_CODE returning a resolver status code “as is” provides useful debugging information needed to debug resolver issues but without any maintenance cost on libcurl side.
Thanks,
Dmitry
From: curl-library <curl-library-bounces_at_lists.haxx.se> On Behalf Of Timothe Litt via curl-library
Sent: Wednesday, April 20, 2022 1:34 PM
To: curl-library_at_lists.haxx.se
Cc: Timothe Litt <litt_at_acm.org>
Subject: Re: Feature request about curlinfo option returning resolver status/error code
On 19-Apr-22 18:26, Dan Fandrich via curl-library wrote:
On Tue, Apr 19, 2022 at 04:14:23PM -0400, Timothe Litt via curl-library wrote:
No. No need to invent abstract codes. Use the DNS RCODE + (if available) the
ENS EDNS0 EDE (RFC8914).
But do those codes include errors that only a local resolver might face? Things
like access or syntax errors on /etc/resolv.conf, inability to connect to the
local resolver daemon, or out of memory? In just looking at the set of c-ares
error codes, they're defined in sections with 6 in the "server error codes"
section and 11 in the "locally-generated error codes" section.
No, but that's why I suggested optionally including resolver-specific codes at the end of the structure.
The point is to allow an application to be independent of the resolver without learning a new, curl-specific vocabulary. And, when new codes are introduced in DNS, not to have to update curl with new abstract codes - at least when the resolver supports getting the actual DNS error code.
You would map any resolver codes that don't come from DNS to a code in the "Reserved for Private Use" space.
You can also provide the text for humans.
See the RFCs and the code registries at:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#extended-dns-error-codes
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
Date: Fri, 22 Apr 2022 19:26:57 +0000
This would make a perfect sense if all resolvers provided most of their codes very close to general DNS RCODEs with a very small resolver-specific set "Reserved for Private Use".
But this is not the case, as far as I can tell, and the resolvers never intended to return status codes close to DNS RCODEs.
The getaddrinfo() error codes are very resolver-specific, and on Windows there is also an OS-specific subset of errors obtained via WSAGetLastError().
So, most of the codes returned by the resolvers will be "Reserved for Private Use", with a very tiny subset from some specific resolvers that can be probably mapped into common DNS RCODEs.
This makes creating and maintaining such mapping not very useful.
And any changes in some resolver status codes will require changes in libcurl to maintain the mapping up to date.
For many different libcurl+resolver combinations it will become a maintenance problem very soon.
When I proposed the CURLINFO_RESOLVER_CODE info option, the main purpose was to help developers to debug resolver-specific issues, when something goes wrong and “opaque” resolver code in case of errors would be a good hint (regardless of whether it is a common DNS problem or some internal resolver issue).
From that perspective, any mapping hiding the resolver code will require additional operation from the developer to do “unmapping” in libcurl first to get to the actual resolver code.
So, a very simple info option, like CURLINFO_RESOLVER_CODE returning a resolver status code “as is” provides useful debugging information needed to debug resolver issues but without any maintenance cost on libcurl side.
Thanks,
Dmitry
From: curl-library <curl-library-bounces_at_lists.haxx.se> On Behalf Of Timothe Litt via curl-library
Sent: Wednesday, April 20, 2022 1:34 PM
To: curl-library_at_lists.haxx.se
Cc: Timothe Litt <litt_at_acm.org>
Subject: Re: Feature request about curlinfo option returning resolver status/error code
On 19-Apr-22 18:26, Dan Fandrich via curl-library wrote:
On Tue, Apr 19, 2022 at 04:14:23PM -0400, Timothe Litt via curl-library wrote:
No. No need to invent abstract codes. Use the DNS RCODE + (if available) the
ENS EDNS0 EDE (RFC8914).
But do those codes include errors that only a local resolver might face? Things
like access or syntax errors on /etc/resolv.conf, inability to connect to the
local resolver daemon, or out of memory? In just looking at the set of c-ares
error codes, they're defined in sections with 6 in the "server error codes"
section and 11 in the "locally-generated error codes" section.
No, but that's why I suggested optionally including resolver-specific codes at the end of the structure.
The point is to allow an application to be independent of the resolver without learning a new, curl-specific vocabulary. And, when new codes are introduced in DNS, not to have to update curl with new abstract codes - at least when the resolver supports getting the actual DNS error code.
You would map any resolver codes that don't come from DNS to a code in the "Reserved for Private Use" space.
You can also provide the text for humans.
See the RFCs and the code registries at:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#extended-dns-error-codes
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-04-22