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: Mon, 25 Apr 2022 19:08:22 +0000
> This suggested option will have a cost too if it should have a functionality.
The maintenance cost of this feature is minimal. The functionality just needs to store the resolver code and return it in the info-option.
After implementing that, there essentially will be no further maintenance because the mechanism of reporting status codes by resolvers is very static and doesn't change.
And the functionality will be agnostic to any status code changes on the resolver side (i.e. adding new codes), whereas any mappings implemented in the libcurl will have to be updated in such cases.
> For example, we need to document the values it can return and then we need to maintain those values in future releases. Applications will assume and depend on the values to be solid.
This feature is meant to be a debugging feature, which can help developers to debug host resolution failures, and such failures can be resolver-specific that go beyond pure DNS-specific problems.
Mapping every possible such resolver-specific case (which can also be OS specific) inside libcurl and documenting all of them is very difficult task.
So, as far as documentation is concerned, I was envisioning that this feature will be documented as "opaque resolver code, which meaning depends on the used resolver backend".
Because this is a debugging feature, there is no need to document more in libcurl, and the application developers can look it up in the resolver code and provide a better information/description if needed.
> We also want to avoid to force applications to need to know about specific libcurl backends and rather keep the API agnostic, but this proposal goes against that. This adds friction to the API.
> So we really need to think that this feature brings at least as much as value as the cost.
They don't need to know, and the API is quite agnostic because it just returns an abstract "resolver code", which has a meaning only for developers debugging issues with some-specific backends.
Some frameworks wrapping around libcurl, know which resolver their libcurl version is using, so they can build mappings for their clients between native resolver codes and text/framework codes to provide a framework-specific error codes and descriptions if needed.
And even if libcurl provides such mappings internally, the resolver-specific codes that reflect some internal resolver issues (which maybe OS-specific) will still have to be looked up in the resolver code to understand what the problem was.
> Does it?
I think it does. The cost of this feature in the form that I proposed is very minimal, but it helps to debug host resolution issues, especially with particular resolvers.
I deal with tricky dual-stack resolution issues with some ISP/routers quite frequently because IPv6 support is still not as good as I would like.
And the resolver codes provide very valuable debugging hints.
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Sunday, April 24, 2022 3:41 PM
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>
Subject: RE: Feature request about curlinfo option returning resolver status/error code
On Fri, 22 Apr 2022, Dmitry Karpov via curl-library wrote:
> 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.
Everything we provide has a maintenance cost.
This suggested option will have a cost too if it should have a functionality.
For example, we need to document the values it can return and then we need to maintain those values in future releases. Applications will assume and depend on the values to be solid.
We also want to avoid to force applications to need to know about specific libcurl backends and rather keep the API agnostic, but this proposal goes against that. This adds friction to the API.
So we really need to think that this feature brings at least as much as value as the cost.
Does it?
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://curl.se/support.html
Date: Mon, 25 Apr 2022 19:08:22 +0000
> This suggested option will have a cost too if it should have a functionality.
The maintenance cost of this feature is minimal. The functionality just needs to store the resolver code and return it in the info-option.
After implementing that, there essentially will be no further maintenance because the mechanism of reporting status codes by resolvers is very static and doesn't change.
And the functionality will be agnostic to any status code changes on the resolver side (i.e. adding new codes), whereas any mappings implemented in the libcurl will have to be updated in such cases.
> For example, we need to document the values it can return and then we need to maintain those values in future releases. Applications will assume and depend on the values to be solid.
This feature is meant to be a debugging feature, which can help developers to debug host resolution failures, and such failures can be resolver-specific that go beyond pure DNS-specific problems.
Mapping every possible such resolver-specific case (which can also be OS specific) inside libcurl and documenting all of them is very difficult task.
So, as far as documentation is concerned, I was envisioning that this feature will be documented as "opaque resolver code, which meaning depends on the used resolver backend".
Because this is a debugging feature, there is no need to document more in libcurl, and the application developers can look it up in the resolver code and provide a better information/description if needed.
> We also want to avoid to force applications to need to know about specific libcurl backends and rather keep the API agnostic, but this proposal goes against that. This adds friction to the API.
> So we really need to think that this feature brings at least as much as value as the cost.
They don't need to know, and the API is quite agnostic because it just returns an abstract "resolver code", which has a meaning only for developers debugging issues with some-specific backends.
Some frameworks wrapping around libcurl, know which resolver their libcurl version is using, so they can build mappings for their clients between native resolver codes and text/framework codes to provide a framework-specific error codes and descriptions if needed.
And even if libcurl provides such mappings internally, the resolver-specific codes that reflect some internal resolver issues (which maybe OS-specific) will still have to be looked up in the resolver code to understand what the problem was.
> Does it?
I think it does. The cost of this feature in the form that I proposed is very minimal, but it helps to debug host resolution issues, especially with particular resolvers.
I deal with tricky dual-stack resolution issues with some ISP/routers quite frequently because IPv6 support is still not as good as I would like.
And the resolver codes provide very valuable debugging hints.
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Sunday, April 24, 2022 3:41 PM
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>
Subject: RE: Feature request about curlinfo option returning resolver status/error code
On Fri, 22 Apr 2022, Dmitry Karpov via curl-library wrote:
> 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.
Everything we provide has a maintenance cost.
This suggested option will have a cost too if it should have a functionality.
For example, we need to document the values it can return and then we need to maintain those values in future releases. Applications will assume and depend on the values to be solid.
We also want to avoid to force applications to need to know about specific libcurl backends and rather keep the API agnostic, but this proposal goes against that. This adds friction to the API.
So we really need to think that this feature brings at least as much as value as the cost.
Does it?
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-04-25