Best way to create a Dapr HttpClient with custom delegating handler?

I have been wondering how to use `DaprClient.CreateInvokeHttpClient` when I have my own HTTP delegating handler in use. My custom http handler will get and add an auth token to outgoing requests.

I'd prefer to avoid having Dapr-specific code all over my codebase so I'm trying to use Dapr in conjunction with an `IHttpClientFactory`. I've created a simple `IHttpClientFactory` implementation which just calls `DaprClient.CreateInvokeHttpClient` and I've registered my delegating handler against the named HttpClient service registration. However, after digging into the Dapr code, I can see that it's just hard-coded to use an `InvocationHandler` and there's no way to change this. So, my custom handler gets lost and never added to the `HttpClient` created by `DaprClient.CreateInvokeHttpClient`.

I cam across this issue from a few years ago which proposed resolving this by allowing consumers to pass a custom handler to `DaprClient.CreateInvokeHttpClient`: https://github.com/dapr/dotnet-sdk/issues/647, but it was rejected with what I think is the suggestion to just manually create your own `HttpClient` with your own http handler, presumably with the Dapr `InvocationHandler` as it's internal handler? Is this correct? I could just copy/paste the code from `DaprClient.CreateInvokeHttpClient` and tweak the http handler bit, but then I have to maintain this and watch for any changes the Dapr team might make in future. This seems somewhat risky. Obviously, as mentioned in the other issue, `InvoationHandler` is public, so I can create that and set it as the internal handler of my own custom handler, but what about the code within the `DaprClient.CreateInvokeHttpClient` itself (setting DaprEndpoint, building and setting the user agent, settings base address etc)? This could change at any time and suddenly Dapr could break when upgrading the NuGet version, because maybe there's some new header or something that's expected.


Maybe the above scenario is unlikely, but frankly I have no idea what _could_ change in future and even if it's not likely to happen, it still feels pretty ugly.

Any ideas/suggestions?

Start by reading DaprClient.CreateInvokeHttpClient and the public InvocationHandler, then compare the described IHttpClientFactory and delegating-handler use case with issue 647. Done means the supported way to compose a custom handler with Dapr's invocation behavior and endpoint, user-agent, base-address, and header setup is documented or clearly identified.

Written by the indexing model from the issue text.