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 F via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 22 Apr 2022 22:10:31 +0200
Hi,
DNS error codes mentioned earlier are returned by DNS itself, so they do
not cover all possible problems. You also need to define values for
various network-related problems (e.g. timeouts, ICMP errors, malformed
packets) and software/configuration ones (e.g. out of memory, permission
denied, invalid arguments, etc.).
Regards,
Daniel
W dniu 2022-04-22 21:26, Dmitry Karpov via curl-library napisał(a):
> 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 22:10:31 +0200
Hi,
DNS error codes mentioned earlier are returned by DNS itself, so they do
not cover all possible problems. You also need to define values for
various network-related problems (e.g. timeouts, ICMP errors, malformed
packets) and software/configuration ones (e.g. out of memory, permission
denied, invalid arguments, etc.).
Regards,
Daniel
W dniu 2022-04-22 21:26, Dmitry Karpov via curl-library napisał(a):
> 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