getaddrinfo calls with a service name fail on Docker images that lack /etc/services

[danports]

Certain Docker images (like mcr.microsoft.com/dotnet/core/runtime-deps:*-bionic/*-stretch-slim, based on Ubuntu/Debian) do not bundle /etc/services, which causes getaddrinfo calls with a service name to fail. I see only one place in this library where a service name is passed to getaddrinfo:
https://github.com/Microsoft/omi/blob/5a2a017f48f616b209d72316bfc8a701ce089a7a/Unix/http/httpclientauth.c#L2565

On affected Docker images, this problem results in authentication failing with a misleading MI_RESULT_ACCESS_DENIED error, and various downstream issues (e.g. you can't use the PowerShell SDK in a Linux .NET Core container running one of the official images listed above to connect to a Windows machine via WSMan).

[JumpingYang001]

@danports any suggestion about how to fix it?

[JumpingYang001]

@danports in fact, omi don't officially support PowerShell now, so I think we might not fix it ...

[danports]

To be clear, this is a problem in this library, not in PowerShell. I am definitely not an expert in this area and haven't tested this, but from what I've read, it should be possible to fix this by passing a string containing a port number (e.g. "80") to getaddrinfo rather than "http".

[JumpingYang001]

80 is a fixed number, I don't think it is a good solution.

[danports]

True, 80 is a fixed number, but what is the risk of the HTTP port changing? Furthermore, it doesn't look like the port passed into the call even matters - the code only uses the ai_canonname field of the addrinfo struct. It doesn't pass the addrinfo struct to connect, so the port number is irrelevant. "http" could be changed to any valid port number passed as a string.

[JumpingYang001]

won't fix.

[danports]

I am very puzzled by your decision to leave this bug unaddressed, especially considering the workaround is so simple. But the decision is yours to make, and I will respect that.

[JumpingYang001]

@danports you can new a PR to fix it as PowerShell is not in our scope now.

[danports]

Alright, I opened #631. Just to clarify, this is an issue in this library whether it is used in the PowerShell stack or not.