Allow HttpRequestMessage to accept relative URLs in service invocation

Background

The Dapr SDK allows invoking service methods using an HttpRequestMessage parameter. However, this overload requires a fully qualified URL to the Dapr sidecar. Otherwise, an InvalidOperationException is thrown.

HttpRequestMessage httpRequest = new(input.HttpMethod, input.MethodName);
return await this.daprClient.InvokeMethodAsync<object?>(httpRequest);

Here is the exception:

System.InvalidOperationException
  HResult=0x80131509
  Message=An invalid request URI was provided. Either the request URI must be an absolute URI or BaseAddress must be set.
  Source=System.Net.Http
  StackTrace:
   at System.Net.Http.HttpClient.PrepareRequestMessage(HttpRequestMessage request)
   at System.Net.Http.HttpClient.CheckRequestBeforeSend(HttpRequestMessage request)
   at System.Net.Http.HttpClient.SendAsync(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at Dapr.Client.DaprClientGrpc.<InvokeMethodWithResponseAsync>d__27.MoveNext()
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Dapr.Client.DaprClientGrpc.<InvokeMethodAsync>d__29`1.MoveNext()
    ...
    [Call Stack Truncated]

Generally speaking, code that already has a fully configured DaprClient should not need to provide redundant endpoint information for the Dapr sidecar. In many cases, it may not be practical for code to know what it is - for example, when getting the DaprClient from dependency injection, in which case the configuration comes from the config system.

Proposal

Remove the requirement in InvokeMethodAsync for the HttpRequestMessage parameter to use a fully qualified URL. The DaprClient implementation can construct the real URL itself using its own internally tracked endpoint. This will make this particular method much easier to use.

[rynowak]

Thanks for the feedback @cgillum

Irrespective of this actual proposal … I’d recommend using https://github.com/dapr/dotnet-sdk/blob/master/src/Dapr.Client/DaprClient.cs#L75 to create an HttpClient and just using the standard .NET APIs. There’s a wealth of existing libraries and knowledge for how to use HttpClient.

[rynowak]

Looking at some of the code in the SDK, it’s my understanding that the endpoint is inferred using the DAPR_GRPC_PORT environment variable. Ideally, I wouldn’t need to redundantly look this up myself if the SDK already knows how to look it up for me.

This is the case, if you omit the endpoint argument then the SDK will do it for you.

You’re not wrong. 😉 However, it seemed to me that the issues I’m running into could be encountered by app developers as well. I believe the patterns I’m following are pretty general. (the “framework” I’m building is actually just a throwaway POC, so these kinds of issues are not blockers, but I thought it might be valuable to raise them anyways).

Alright cool 😆 - feel free to reach out if you want to spend some time talking in details.