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: Timothe Litt <litt_at_acm.org>
Date: Wed, 20 Apr 2022 16:34:27 -0400
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.
Received on 2022-04-20
Date: Wed, 20 Apr 2022 16:34:27 -0400
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.html
- application/pgp-signature attachment: OpenPGP digital signature