UseHttpEndpoint ignored unless DAPR_GRPC_PORT is set in .NET SDK

[Hamza091]

Expected Behavior

I expected the Dapr .NET SDK to communicate over HTTP when explicitly configured with UseHttpEndpoint, without requiring gRPC-related environment variables (DAPR_GRPC_PORT, DAPR_GRPC_ENDPOINT).

---

Actual Behavior

• With only HTTP environment variables set (DAPR_HTTP_PORT, DAPR_HTTP_ENDPOINT), the client throws connection refused errors.
• The client only works after adding gRPC environment variables, even though my code is configured to use HTTP.
• This suggests that the SDK may be defaulting to gRPC communication, ignoring the explicit HTTP configuration.

---

Steps to Reproduce the Problem

1. Create a .NET service with the following Dapr client configuration:

   builder.Services.AddDaprClient(daprClientBuilder =>
   {
       var daprHttpPort = builder.Configuration.GetValue<string>("DAPR_HTTP_PORT") ?? "3500";
       daprClientBuilder.UseHttpEndpoint($"http://channelservice-api-dapr:{daprHttpPort}");
       daprClientBuilder.UseTimeout(TimeSpan.FromSeconds(60));
   });

2. Run the service in Docker Compose with only HTTP env variables:

environment:
  - DAPR_HTTP_PORT=3500
  - DAPR_HTTP_ENDPOINT=http://channelservice-api-dapr:3500

Result: Client fails with connection refused.

3. Add gRPC env variables to the same service:

environment:
  - DAPR_GRPC_PORT=50002
  - DAPR_GRPC_ENDPOINT=http://channelservice-api-dapr:50002
  - DAPR_HTTP_PORT=3500
  - DAPR_HTTP_ENDPOINT=http://channelservice-api-dapr:3500

Result: Client starts working, despite code being configured to use HTTP.

[WhitWaldo]

Unlike some of the other SDKs that offer a choice of how you want to connect to the runtime, the .NET SDK primarily uses gRPC and only uses HTTP for some of the legacy functionality.

As this is communication between the SDK and the runtime (e.g. your app shouldn't have anything to do with it), might I ask why you'd want to use HTTP instead?

[Hamza091]

Thanks for the clarification! That makes sense.

However, the documentation does seem a bit misleading in this area. For example, it states:

Configuring From Environment Variables
The SDK will read the following environment variables to configure the default values:

• DAPR_HTTP_ENDPOINT: used to find the HTTP endpoint of the Dapr sidecar, example: https://dapr-api.mycompany.com
• DAPR_GRPC_ENDPOINT: used to find the gRPC endpoint of the Dapr sidecar, example: https://dapr-grpc-api.mycompany.com
• DAPR_HTTP_PORT: if DAPR_HTTP_ENDPOINT is not set, this is used to find the HTTP local endpoint of the Dapr sidecar
• DAPR_GRPC_PORT: if DAPR_GRPC_ENDPOINT is not set, this is used to find the gRPC local endpoint of the Dapr sidecar
• DAPR_API_TOKEN: used to set the API Token

(Source: Dapr .NET SDK documentation)

From this description, it gives the impression that setting the HTTP variables alone should be sufficient for communication — but in practice, the .NET SDK only works once gRPC env vars are set.

It might help if the docs explicitly called out that:

• The .NET SDK primarily communicates with the runtime over gRPC, and
• HTTP environment variables are only used for limited/legacy functionality.

That way, developers won’t assume they can rely on HTTP-only configuration when using the .NET SDK.

[WhitWaldo]

That makes sense. We're largely just impacted by the evolution of the runtime and SDK here in that many of the original pieces were HTTP-only and recent blocks were implemented only with gRPC. While it's certainly my goal to eventually have the SDK exclusively use gRPC, that's certainly a large undertaking and almost certainly not something that'll be done anytime soon.

That said, I can certainly work to make the documentation clearer on this front and will do so this release.