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.
OpenPGP_signature
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
