Use "localhost" instead of "127.0.0.1" for the sidecar host address

[cgillum]

Describe the proposal

Currently we use 127.0.0.1 when accessing the Dapr sidecar from the .NET SDK. This is hardcoded here. We should change this to instead be localhost because:

1. 127.0.0.1 only works with IPv4 whereas localhost works with both IPv4 and IPv6.
2. Unlike with localhost, using 127.0.0.1 can't resolve to local WSL2 endpoints from the Windows OS, which is a hindrance for local dev/test on Windows.

As an alternative, we could consider making the host address configurable via an environment variable.

[ondmal]

Hi @cgillum.

As an alternative, we could consider making the host address configurable via an environment variable.

• Do you have any proposal for the environment variable name?
• Do you still want to use localhost if the environment variable is not defined?

[cgillum]

Thanks for the response @ondmal.

Do you have any proposal for the environment variable name?

Just throwing this out there, but how about DAPR_HOST?

Do you still want to use localhost if the environment variable is not defined?

Yes, the switch to localhost solves the immediate blockers that I'm running into more easily than an environment variable would.

[ondmal]

I do not know the system well, so I can´t say what is already reserved. But DAPR_HOST looks good to me.

EDIT: Looks like DAPR_HOST is good fit, since it is already used in the code base:

https://github.com/search?p=1&q=org%3Adapr+DAPR_HOST&type=Code

but it is missing here in docs: https://docs.dapr.io/reference/environment/

[itpropro]

Any updates on this? This is regularly coming up in local Windows dev environments.

[WhitWaldo]

@itpropro This is accommodated by the new DI registration for each Dapr client that will release with 1.15.

The conversation specifically covered on this thread was superseded by a consistent envvar used by all the SDKs for DAPR_HTTP_ENDPOINT or DAPR_GRPC_ENDPOINT. The update I referenced will first look for the necessary values from the options provided during the DI registration, then attempt to retrieve from an IConfiguration and finally pull from the environment variables as a fallback.

If not set across the board, it defaults to using localhost instead of '127.0.0.1` with the default Dapr ports (3500 for HTTP and 50001 for gRPC).

I would encourage you to try using the latest Dapr .NET SDK RC and see if it solves your local issues.

[itpropro]

@itpropro This is accommodated by the new DI registration for each Dapr client that will release with 1.15.

The conversation specifically covered on this thread was superseded by a consistent envvar used by all the SDKs for DAPR_HTTP_ENDPOINT or DAPR_GRPC_ENDPOINT. The update I referenced will first look for the necessary values from the options provided during the DI registration, then attempt to retrieve from an IConfiguration and finally pull from the environment variables as a fallback.

If not set across the board, it defaults to using localhost instead of '127.0.0.1` with the default Dapr ports (3500 for HTTP and 50001 for gRPC).

I would encourage you to try using the latest Dapr .NET SDK RC and see if it solves your local issues.

I just tried with

CLI version: 1.15.0-rc.6
Runtime version: 1.15.0-rc.16

But it's still the same error.
The dapr dashboard even lists the correct address for the registered service

But when calling it from another application with the respective dapr-app-id header, dapr still tries to access it with 127.0.0.1.
failed to invoke, id: MYAPPID, err: rpc error: code = Internal desc = error invoking app channel: Post \u0022http://127.0.0.1:3001/PARAMS: dial tcp 127.0.0.1:3001: connectex: No connection could be made because the target machine actively refused it.

Currently the only way around this is to explicitly run all local services with 127.0.0.1 as host, which has a lot of other implications, every other tooling can handle and expects the localhost DNS name.

Can you please reopen the issue until it is really fixed @WhitWaldo ?

EDIT: I have set DAPR_HOST=http://localhost for every microservice and DAPR_PORT=3500 accordingly to with which port it was started.

[WhitWaldo]

@itpropro I'd argue yours is a little bit of a different issue than what was originally raised, but I'm happy to tackle it here.

Can you confirm that your other app is using the .NET SDK?