"http://" to default to port 80 in gRPC endpoint

[artursouza]

Our custom logic for gRPC endpoint parsing default "http" to 443, which is not compatible to how users would expect the URL spec to behave. I understand that the gRPC endpoint and URL spec are not the same thing but when an user writes the environment variable for gRPC with HTTP URL terminology, we should respect the default ports expected as per the standard URL RFC (needs link to RFC). Defaulting to port 443 does not bring any extra security, since the port itself does not mean TLS, it is just a convention - a service can perfectly run without TLS on port 443. IMO, going against the RFC is not user-friendly for default port convention.

This proposal is to change the expected port to 80 when the user specifies "http://" as the prefix for the gRPC endpoint: https://github.com/dapr/proposals/blob/main/20230627-S-sidecar-endpoint-tls.md#test-matrix

I would like to collect quantitative data about how the community feels one way or another.

👍 For this proposal
👎 To keep it as-is

[artursouza]

The Java SDK has an existing unit test that detected this regression as well from the update on the spec. I have cut a PR: #57

[JoshVanL]

I agree that ports in the gRPC world are in practice arbitrary and sub 1024 ports are only interesting because of legacy 1990s RFC reasons. As I remember, using 443 as the default HTTP "name resolver" port was chosen as it was considered the "safest" given it's reserved for HTTPS and therefore has the least chance of unintended unencrypted communication with a server using a defaulted client config.

If this is causing problems with backwards compat/UX I'm +1 as again, ports are generally arbitrary- with the caveat that we are not making it more likely that a user connects to a server unencrypted unintentionally.

[artursouza]

Yes, I remember the discussion. Ports are arbitrary indeed and is about convention. The difference is that (IMO) when prefixing with HTTP or HTTPS, the user is coming from an HTTP perspective (like .Net does natively). I think that by using HTTP, user's intention is for port 80 and defaulting to 443 would be forcing the other way around - which (again) is not the user's intention in this case IMO.