Simon Josefsson wrote:
> 1) Supporting a complete list takes up a lot of size. Not all projects
> use non-numeric service fields in getaddrinfo, so it can be wasteful.
Then what about a shorter list? Let's say, only the 20 to 100 protocols
defined by RFCs (because only they are likely to be relevant for free
software), not the thousands of proprietary protocols?
> 2) Hard coding the service <-> port mappings breaks the ability to
> modify port numbers by editing /etc/services or using NIS or whatever.
The getaddrinfo replacement would, of course, first try the system's
getaddrinfo, and only upon failure, look in its own table.
> 3) Detecting whether the system's internal getaddrinfo has failed only
> because of an unsupported service may be trickier.
Is it so tricky? When getaddrinfo("somehost", "foo", ...) fails:
- If the errno code is one of the three we know about:
- If "foo" is in our own table:
Retry getaddrinfo("somehost", numeric-foo, ...).
- Otherwise, if errno is EAI_NONAME or EAI_NODATA, try
getaddrinfo("somehost", "80", ...). If that succeeds, return EAI_SERVICE,
otherwise return EAI_NODATA (or should it be EAI_NONAME??).
- Otherwise simply forward the system's getaddrinfo return code.
> We could add a wrapper
> to, on these error codes and for these systems, re-try any failed call
> for "https" with a call for "443", to see if that succeeds.
Yes.
> If we re-try (failed) queries for, say 'http', too, we may introduce
> surprising behavior: consider if the system maps 'http' to port 8080,
> and that lookup fails because no such service is registered [1], and we
> re-try it using port 80 instead, which could succeed.
I think users would consider it a feature, not a bug, if the replacement
function hides a bug in /etc/services. Service names are meant to be system
independent, after all.
Bruno
