Usage of the HttpMessageHandlerBuilder.Name property in production code

[iliar-turdushev]

Hello,

The documentation clearly says that the HttpMessageHandlerBuilder.Name property is public for unit testing only. I believe it means that it is not safe to use it in production code and breaking changes could be made to this property without any notice, right? Are you considering making it available for usage in production code too? It could be useful in scenarios like the following:

services.ConfigureHttpClientDefaults(clientBuilder =>
{
    clientBuilder.Services.ConfigureAll<HttpClientFactoryOptions>(options =>
    {
        options.HttpMessageHandlerBuilderActions.Add(handlerBuilder =>
        {
            // Use handlerBuilder.Name, e.g. to emit telemetry that includes name of HttpClient.
        });
    });
});

Thank you.

Tagging @CarnaViire, because we discussed similar topic some time ago.

[CarnaViire]

All behavioral breaking changes will be always properly documented. HttpMessageHandlerBuilder.Name is part of the public API surface, which means there could be users who rely on it. So if any breaking change, including obsoletion, happens in that area, there will be always a doc, and a workaround provided.

So from that perspective, you can use it in production as well. At the moment, I don't see anything that should prevent you from using HttpMessageHandlerBuilder.Name property.

What's more, at the moment, this property is (unfortunately) the only way to access the name of a specific client within a "global" (="for all clients") configuration -- be it ConfigureHttpClientDefaults or ConfigureAll<HttpClientFactoryOptions> -- due to the nature of the Options pattern, which regards null as "all" 🥲

(This was discussed in #101719. I am long due to create a separate issue about enabling a more convenient Name access.... I will file that shortly)

---

However, if you decide to (or even have to) use HttpMessageHandlerBuilder in general, please be aware of the following:

1. It is technically possible for the end-user to override HttpMessageHandlerBuilder implementation in the DI container (in the same way as even the whole IHttpClientFactory can be substituted). Any behavioral guarantees will only apply to the default implementations which are registered within AddHttpClient call (e.g. see HttpClientFactoryServiceCollectionExtensions.cs)

2. HttpMessageHandlerBuilderActions property might get deprecated in the future (in the same way and due to the same reason that ConfigureHttpMessageHandlerBuilder method is already deprecated). However, that will happen if and only if we introduce an API that will provide a proper access to the Name of the client from the callbacks.

---

BTW, I must ask, in the code snippet you provided, is there a reason clientBuilder.Services from ConfigureHttpClientDefaults is used instead of just plain services.ConfigureAll @iliar-turdushev?

[CarnaViire]

I am long due to create a separate issue about enabling a more convenient Name access.... I will file that shortly

#110167

[iliar-turdushev]

Thank you for the information.

BTW, I must ask, in the code snippet you provided, is there a reason clientBuilder.Services from ConfigureHttpClientDefaults is used instead of just plain services.ConfigureAll @iliar-turdushev?

You're right. There is no reason to use ConfigureAll from inside ConfigureHttpClientDefaults, there is even no reason to use ConfigureHttpClientDefaults in that sample at all. I was creating that code sample having in mind the behavior of ConfigureHttpClientDefaults that it always has IHttpClientBuilder.Name == null, and therefore by mistake included it into the sample. It can be removed, and it is not related to the question.