Question: How to use different http message handlers for CallHttpAsync() #1763
-
Hi, currently i am building durable functions and need to reach out to different endpoints from the orchestrator. I have created a custom implementation of IDurableHttpMessageHandlerFactory and added client certificate from keyvault because for one external endpoint i need to authenticate like that. For a different endpoint, i dont need this and i dont want to use the same handler for this. In startup i have: builder.Services.AddSingleton<IDurableHttpMessageHandlerFactory, DurableHttpHandlerFactory>(); but i dont think there is another of adding multiple implementations of IDurableHttpMessageHandlerFactory? What would be a proper way to support different httpclients from durables? thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
We do not have a way to have different HttpMessageHandlers for different calls to We could have theoretically supported this if we had an optional parameter on The way to work around this in the meantime would be to return a HttpMessageHandler that is itself a composite For example: public class CertificateHandler : DelegatingHandler
{
protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
if (IsCertAuthRequest(request))
{
// Logic to add cert based authentication to request
}
return base.SendAsync(request, cancellationToken);
}
private static bool IsCertAuthRequest(HttpRequestMessage request)
{
// Look at HTTP request to decide if we should handle it in this layer
return true;
}
} You would then instantiate that object like new CertificateHandler(new HttpClientHandler()) |
Beta Was this translation helpful? Give feedback.
-
Connor, thanks for your feedback. And for the direction on how to handle this. This approach seems viable yes. regards |
Beta Was this translation helpful? Give feedback.
We do not have a way to have different HttpMessageHandlers for different calls to
CallHttpAsync()
.We could have theoretically supported this if we had an optional parameter on
IDurableHttpMessageHandlerFactory.CreateHttpMessageHandler()
to specify a handler name, and letCallHttpAsync()
pass in handler names, but since the interface is public, we can't add new optional parameters in a non-breaking way.The way to work around this in the meantime would be to return a HttpMessageHandler that is itself a composite
HttpMessageHandler
. It can observe characteristics of the HTTP request (such as the endpoint being targeted, headers on the request, etc.) and make a decision about which of it's …