Add API to provide existing DI scope to HttpClientFactory

[CarnaViire]

Updated

The scope can be provided via the keyed services infra. The API to opt-in into Keyed services registration is proposed in #89755.

AddAsKeyedScoped() API will automatically opt in into the scope-propagating behavior, but ONLY in case keyed services infra ([FromKeyedServices...] or GetRequiredKeyedService) is used to inject/resolve the client.

Opt-in API design considerations -- separate from keyed services

namespace Microsoft.Extensions.DependencyInjection;

public static partial class HttpClientBuilderExtensions
{
    public static IHttpClientBuilder SetPropagateContextScope(this IHttpClientBuilder builder, bool val) {}
}

Usage:

services.AddHttpClient("foo")
    //.AddAsKeyedScoped()
    .SetPropagateContextScope(true);

services.AddHttpClient("foo")
    //.AddAsKeyedTransient()
    .SetPropagateContextScope(true); // if there are any scoped dependencies, won't resolve in singletons

services.AddHttpClient("foo")
    .SetPropagateContextScope(false); // explicitly opt-out

Alternalive namings:

• PropagateScope
• PropagateExistingScope
• SetPreserveExistingScope(true/false)
• SetSuppressHandlerScope(true/false) (there is existing "hidden" option with that name, but the usage is a bit different, so technically it can clash with existing usages + and not self-evident name)

---

Original proposal

Background and Motivation

HttpClientFactory allows users to register one or several HttpClient configurations in DI container and then instantiate HttpClients according to the respective configuration. A configuration can specify that HttpClient should use a specific HttpMessageHandler or even a chain of such handlers. When creating a client, HttpClientFactory caches and reuses HttpMessageHandlers to avoid creating too many connections and exhausting sockets, so handlers will live for a configurable timespan HandlerLifetime.

The problem begins when message handlers forming a chain have dependencies on other services from DI. In case the user wants to inject a scoped service into the message handler, they expect the scoped service instance to be from their existing unit-of-work scope. However, the current behavior is different -- in the existing implementation, the service instance will be from a new scope bound to message handler lifetime, i.e. it will be a different instance from what the user would expect.

This scope mismatch is not only confusing to customers, but also produces unsolvable bugs in user code, e.g. when the scoped service is supposed to be stateful within the scope, but this state is impossible to access from the message handler.

There is a number of GH issues and StackOverflow questions from users suffering from scope mismatch:

• HttpClientFactory doesn't respect lifetime of custom message handlers #36574 HttpClientFactory doesn't respect lifetime of custom message handlers
• DefaultHttpClientFactory working incorrectly with Scoped dependencies #42344 DefaultHttpClientFactory working incorrectly with Scoped dependencies
• c# - Prevent IHttpClientFactory to create DI scope for handlers - Stack Overflow
• c# - Configure HttpClientFactory to use data from the current request context - Stack Overflow
• IHttpClientBuilder with DelegatingHandler creates additional scope in Blazor webassembly - Stack Overflow

The solution leverages the following idea:

If we want to cache/reuse the connection, it is enough to cache/reuse the bottom-most handler of the chain (aka PrimaryHandler). Other handlers in the chain may be re-instantiated for each unit-of-work scope, so they will have the correct instances of the scoped services injected into them (which is desired by customers).

I believe new behavior should be opt-in, as there will be more allocations than before.

However, in order to leverage existing scope, HttpClientFactory should know about it. In the current implementation, the factory is registered in DI a singleton, so it doesn't have access to scopes.

The easiest way to allow HttpClientFactory to capture existing scope is to change its lifetime from singleton to transient. Transient services can (as well as singletons) be injected into services of all lifetimes, so all existing code will continue to work.

To maintain existing caching behavior, cache part of the factory will be moved out to a separate singleton service, but this is an implementation detail that does not affect API.

Proposed API

namespace Microsoft.Extensions.DependencyInjection
{
    public static partial class HttpClientBuilderExtensions
    {
        ...
        public static IHttpClientBuilder SetHandlerLifetime(this IHttpClientBuilder builder, TimeSpan handlerLifetime) { ... }
+       public static IHttpClientBuilder SetPreserveExistingScope(this IHttpClientBuilder builder, bool preserveExistingScope) { ... }
    }
}

namespace Microsoft.Extensions.Http
{
    public partial class HttpClientFactoryOptions
    {
        ...
        public TimeSpan HandlerLifetime { get; set; }
+       public bool PreserveExistingScope { get; set; } // default is false = old behavior
    }
}

namespace System.Net.Http
{
-   // registered in DI as singleton
+   // registered in DI as transient
    public partial interface IHttpClientFactory
    {
        HttpClient CreateClient(string name);
    }
}

Usage Examples

The only change needed for both named and typed clients is to opt-in via callling SetPreserveExistingScope(true)

Named client example:

// registration
class Program
{
    private static void ConfigureServices(HostBuilderContext context, IServiceCollection services)
    {
        services.AddScoped<IWorker, NamedClientWorker>();
        services.AddScoped<HandlerWithScopedDependency>();
        services.AddHttpClient("github")
            .AddHttpMessageHandler<HandlerWithScopedDependency>()
+           .SetPreserveExistingScope(true);
        ...
    }
    ...
}

// usage
class NamedClientWorker : IWorker
{
   private IHttpClientFactory _clientFactory;

+   // HttpClientFactory will capture an existing scope where it was resolved
    public NamedClientWorker(IHttpClientFactory clientFactory)
    {
        _clientFactory = clientFactory;
    }

    public async Task DoWorkAsync()
    {
+       // HandlerWithScopedDependency inside HttpClient will be resolved
+       // within an existing scope 
        HttpClient client = _clientFactory.CreateClient("github");
        var response = await client.GetStringAsync(GetRepositoriesUrl(username));
        ...
    }
}

Typed client example:

// registration
class Program
{
    private static void ConfigureServices(HostBuilderContext context, IServiceCollection services)
    {
        services.AddScoped<IWorker, TypedClientWorker>();
        services.AddScoped<HandlerWithScopedDependency>();
        services.AddHttpClient<IGithubClient, GithubClient>
            .AddHttpMessageHandler<HandlerWithScopedDependency>()
+           .SetPreserveExistingScope(true);
        ...
    }
    ...
}

// usage
class TypedClientWorker : IWorker
{
    private IGithubClient _githubClient;

    public TypedClientWorker(IGithubClient githubClient)
    {
        _githubClient = githubClient;
    }

    public async Task DoWorkAsync()
    {
        var response = await _githubClient.GetRepositories(username);
        ...
    }
}

// typed client impl
class GithubClient : IGithubClient
{
    private HttpClient _client;

    // HttpClient is created by IHttpClientFactory  
+   // HttpClientFactory will capture an existing scope
+   // HandlerWithScopedDependency inside HttpClient will be resolved
+   // within an existing scope 
    public GithubClient(HttpClient client)
    {
        _client = client;
    }

    public async Task<string> GetRepositories(string username)
    {
        return await _client.GetStringAsync(GetRepositoriesUrl(username));
    }
}

Alternative Designs

If we don't want to change the current lifetime of HttpClientFactory (i.e. let it stay singleton), we should provide the scope to it in some other way.

In order to do that, we may have an additional scoped service, which will have access to the current unit-of-work scope and to the singleton HttpClientFactory.

Let me note that because of how DI works, we couldn't use existing interface IHttpClientFactory for a new scoped service, because a singleton service is already registered on it. That's why a new interface IScopedHttpClientFactory is added here.

namespace Microsoft.Extensions.DependencyInjection
{
    public static partial class HttpClientBuilderExtensions
    {
        ...
        public static IHttpClientBuilder SetHandlerLifetime(this IHttpClientBuilder builder, TimeSpan handlerLifetime) { ... }
+       public static IHttpClientBuilder SetPreserveExistingScope(this IHttpClientBuilder builder, bool preserveExistingScope) { ... }
    }
}

namespace Microsoft.Extensions.Http
{
    public partial class HttpClientFactoryOptions
    {
        ...
        public TimeSpan HandlerLifetime { get; set; }
+       public bool PreserveExistingScope { get; set; } // default is false = old behavior
    }
}

namespace System.Net.Http
{
    // registered in DI as singleton
    public partial interface IHttpClientFactory
    {
        HttpClient CreateClient(string name);
    }

+   // registered in DI as scoped
+   public partial interface IScopedHttpClientFactory
+   {
+       HttpClient CreateClient(string name);
+   }
}

Alternative design's usage examples:

For named clients, user will also need to change the injected factory after opt-in. For typed clients, just opting-in is enough, the magic will happen on its own.

Named client example:

// registration
class Program
{
    private static void ConfigureServices(HostBuilderContext context, IServiceCollection services)
    {
        services.AddScoped<IWorker, NamedClientWorker>();
        services.AddScoped<HandlerWithScopedDependency>();
        services.AddHttpClient("github")
            .AddHttpMessageHandler<HandlerWithScopedDependency>()
+           .SetPreserveExistingScope(true);
        ...
    }
    ...
}

// usage
class NamedClientWorker : IWorker
{
-   private IHttpClientFactory _clientFactory;
+   private IScopedHttpClientFactory _clientFactory;

    public NamedClientWorker(
-       IHttpClientFactory clientFactory)
+       IScopedHttpClientFactory clientFactory)
    {
        _clientFactory = clientFactory;
    }

    public async Task DoWorkAsync()
    {
        HttpClient client = _clientFactory.CreateClient("github");
        var response = await client.GetStringAsync(GetRepositoriesUrl(username));
        ...
    }
}

Typed client example:

// registration
class Program
{
    private static void ConfigureServices(HostBuilderContext context, IServiceCollection services)
    {
        services.AddScoped<IWorker, TypedClientWorker>();
        services.AddScoped<HandlerWithScopedDependency>();
        services.AddHttpClient<IGithubClient, GithubClient>
            .AddHttpMessageHandler<HandlerWithScopedDependency>()
+           .SetPreserveExistingScope(true);
        ...
    }
    ...
}

// usage
class TypedClientWorker : IWorker
{
    private IGithubClient _githubClient;

    public TypedClientWorker(IGithubClient githubClient)
    {
        _githubClient = githubClient;
    }

    public async Task DoWorkAsync()
    {
        var response = await _githubClient.GetRepositories(username);
        ...
    }
}

// typed client impl
class GithubClient : IGithubClient
{
    private HttpClient _client;

-   // HttpClient is created by IHttpClientFactory 
+   // HttpClient is automatically created by IScopedHttpClientFactory after opt-in
    public GithubClient(HttpClient client)
    {
        _client = client;
    }

    public async Task<string> GetRepositories(string username)
    {
        return await _client.GetStringAsync(GetRepositoriesUrl(username));
    }
}

Risks

For existing usages - the risk is low. Transient HttpClientFactory can be injected in all service lifetimes as well as a singleton, so all existing code will continue to work as before and will maintain old behavior for creating HttpMessageHandlers. The only thing that will change is that there will be more allocations (every injection of HttpClientFactory will create a new instance).

New opt-in behavior is only meaningful within a scope, so HttpClientFactory should be resolved within a scope for PreserveExistingScope=true to work. However, no need to add any additional checks, this will be checked by DI's Scope Validation.

Substituting or modifying PrimaryHandler in case of PreserveExistingScope=true will be currently forbidden (InvalidOperationException during DI configuration). This is due to inability to assess security risks and avoid unnesessary object creations. HttpMessageHandlerBuilder.Build() will be called for each scope and not once in a (primary) handler lifetime as before. If it contains substituting or modifying PrimaryHandler, it will not work as expected, but will produce potential security risk and impact performance by creating redundant PrimaryHandlers to be thrown away. Addressing the risks of allowing PrimaryHandler modification will require additional API change.

---

2021-02-11 Edit: Changed main proposal to be about transient HttpClientFactory. Moved IScopedHttpClientFactory to alternatives. Removed option with IServiceProvider completely as it is both a bad practice and inconvenient to use.

2021-01-21 Edit: I've removed IScopedHttpMessageHandlerFactory from the proposal. It was initially added to correlate with IHttpMessageHandlerFactory, but actual usage examples where only scoped message handler would be needed but not HttpClient are not clear. It can be easily added later if there will be any demand for that.

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and Motivation

HttpClientFactory allows users to register one or several HttpClient configurations in DI container and then instantiate HttpClients according to the respective configuration. A configuration can specify that HttpClient should use a specific HttpMessageHandler or even a chain of such handlers. When creating a client, HttpClientFactory caches and reuses HttpMessageHandlers to avoid creating too many connections and exhausting sockets, so handlers will live for a configurable timespan HandlerLifetime.

The problem begins when message handlers forming a chain have dependencies on other services from DI. In case the user wants to inject a scoped service into the message handler, they expect the scoped service instance to be from their existing unit-of-work scope. However, the current behavior is different -- in the existing implementation, the service instance will be from a new scope bound to message handler lifetime, i.e. it will be a different instance from what the user would expect.

This scope mismatch is not only confusing to customers, but also produces unsolvable bugs in user code, e.g. when the scoped service is supposed to be stateful within the scope, but this state is impossible to access from the message handler.

There is a number of GH issues and StackOverflow questions from users suffering from scope mismatch:

• HttpClientFactory doesn't respect lifetime of custom message handlers #36574 HttpClientFactory doesn't respect lifetime of custom message handlers
• Loss of scoped lifetime service instances when resolving HttpClient services configured through IServiceCollection.AddHttpClient(...) #42142 Loss of scoped lifetime service instances when resolving HttpClient services configured through IServiceCollection.AddHttpClient(...)
• DefaultHttpClientFactory working incorrectly with Scoped dependencies #42344 DefaultHttpClientFactory working incorrectly with Scoped dependencies
• c# - Prevent IHttpClientFactory to create DI scope for handlers - Stack Overflow
• c# - Configure HttpClientFactory to use data from the current request context - Stack Overflow

The solution leverages the following idea:

If we want to cache/reuse the connection, it is enough to cache/reuse the bottom-most handler of the chain (aka PrimaryHandler). Other handlers in the chain may be re-instantiated for each unit-of-work scope, so they will have the correct instances of the scoped services injected into them (which is desired by customers).

I believe new behavior should be opt-in, as there will be more allocations than before.

However, in order to leverage existing scope, it should be passed to HttpClientFactory from outside. The factory itself is a singleton, so it doesn't have access to scopes.

In order to do that, we may have an additional scoped service, which will have access to the current unit-of-work scope and to the singleton HttpClientFactory (which is proposed below). The alternative could be to make users provide the specific scoped IServiceProvider to the factory themselves.

Proposed API

namespace Microsoft.Extensions.DependencyInjection
{
    public static partial class HttpClientBuilderExtensions
    {
        ...
        public static IHttpClientBuilder SetHandlerLifetime(this IHttpClientBuilder builder, TimeSpan handlerLifetime) { ... }
+       public static IHttpClientBuilder SetPreserveExistingScope(this IHttpClientBuilder builder, bool preserveExistingScope) { ... }
    }
}

namespace Microsoft.Extensions.Http
{
    public partial class HttpClientFactoryOptions
    {
        ...
        public TimeSpan HandlerLifetime { get; set; }
+       public bool PreserveExistingScope { get; set; } // default is false = old behavior
    }
}

namespace System.Net.Http
{
    // registered in DI as singleton
    public partial interface IHttpClientFactory
    {
        HttpClient CreateClient(string name);
    }

    // registered in DI as singleton
    public partial interface IHttpMessageHandlerFactory
    {
        HttpMessageHandler CreateHandler(string name);
    }

+   // registered in DI as scoped
+   public partial interface IScopedHttpClientFactory
+   {
+       HttpClient CreateClient(string name);
+   }

+   // registered in DI as scoped
+   public partial interface IScopedHttpMessageHandlerFactory
+   {
+       HttpMessageHandler CreateHandler(string name);
+   }
}

Usage Examples

For named clients, user will also need to change the injected factory after opt-in. For typed clients, just opting-in is enough, the magic will happen on its own.

// registration
class Program
{
    private static void ConfigureServices(HostBuilderContext context, IServiceCollection services)
    {
        services.AddScoped<HandlerWithScopedDependency>();

        // named client
        services.AddHttpClient("github")
            .AddHttpMessageHandler<HandlerWithScopedDependency>()
+           .SetPreserveExistingScope(true);

        // typed client
        services.AddHttpClient<IGithubClient, GithubClient>
            .AddHttpMessageHandler<HandlerWithScopedDependency>()
+           .SetPreserveExistingScope(true);
        ...
    }
    ...
}

// usage
class Worker : IWorker
{
-   private IHttpClientFactory _clientFactory;
+   private IScopedHttpClientFactory _clientFactory;
    private IGithubClient _githubClient;

    public Worker(
-       IHttpClientFactory clientFactory,
+       IScopedHttpClientFactory clientFactory,
        IGithubClient githubClient)
    {
        _clientFactory = clientFactory;
        _githubClient = githubClient;
    }

    public async Task DoWorkWithNamedClientAsync()
    {
        HttpClient client = _clientFactory.CreateClient("github");
        var response = await client.GetStringAsync(GetRepositoriesUrl(username));
        ...
    }

    public async Task DoWorkWithTypedClientAsync()
    {
        var response = await _githubClient.GetRepositories(username);
        ...
    }
}

// typed client impl
class GithubClient : IGithubClient
{
    private HttpClient _client;

    // client is created by IScopedHttpClientFactory after opt-in
    public GithubClient(HttpClient client)
    {
        _client = client;
    }

    public async Task<string> GetRepositories(string username)
    {
        return await _client.GetStringAsync(GetRepositoriesUrl(username));
    }
}

Alternative Designs

The alternative could be to make users provide the specific scoped IServiceProvider to the factory themselves. This however will require them to inject IServiceProvider to every service they use the factory in. In my opinion, this is a bit messy and will dangerously tempt users to leverage a service locator antipattern.

namespace System.Net.Http
{
    public partial interface IHttpClientFactory
    {
        HttpClient CreateClient(string name);
+       HttpClient CreateClient(string name, IServiceProvider serviceProvider);
    }

    public partial interface IHttpMessageHandlerFactory
    {
        HttpMessageHandler CreateHandler(string name);
+       HttpMessageHandler CreateHandler(string name, IServiceProvider serviceProvider);
    }
}

Usage example:

class Worker : IWorker
{
+   private IServiceProvider _serviceProvider;
    private IHttpClientFactory _clientFactory;

    public Worker(
+       IServiceProvider serviceProvider,
        IHttpClientFactory clientFactory)
    {
+       _serviceProvider = serviceProvider;
        _clientFactory = clientFactory;
    }

    public async Task DoWorkWithNamedClientAsync()
    {
-       HttpClient client = _clientFactory.CreateClient("github");
+       HttpClient client = _clientFactory.CreateClient("github", _serviceProvider);
        var response = await client.GetStringAsync(GetRepositoriesUrl(username));
        ...
    }
}

I also want to mention that I did not consider changing HttpClientFactory's own lifetime (e.g. from singleton to scoped) as it will be too much of a breaking change, e.g. scoped services cannot be injected into singletons, but other singletons can, so if current singleton factory was injected into a singleton somewhere, it will break.

Risks

For existing usages - the risk is low, because new behavior is opt-in. Existing usages will maintain old behavior.

Using IHttpClientFactory with PreserveExistingScope=true, as well as using IScopedHttpClientFactory with PreserveExistingScope=false will produce an InvalidOperationException to avoid confusing behavior (e.g. no scope to preserve in singleton IHttpClientFactory).

Substituting or modifying PrimaryHandler in case of PreserveExistingScope=true will be currently forbidden (InvalidOperationException during DI configuration). This is due to inability to assess security risks and avoid unnesessary object creations. HttpMessageHandlerBuilder.Build() will be called for each scope and not once in a (primary) handler lifetime as before. If it contains substituting or modifying PrimaryHandler, it will not work as expected, but will produce potential security risk and impact performance by creating redundant PrimaryHandlers to be thrown away. Addressing the risks of allowing PrimaryHandler modification will require additional API change.

Author:	CarnaViire
Assignees:	-
Labels:	api-suggestion, area-Extensions-HttpClientFactory
Milestone:	-

[davidfowl]

👀

[halter73]

IScopedHttpClientFactory and IScopedHttpMessageHandlerFactory are interesting. My knee-jerk reaction is that we shouldn't add these interfaces because there's no enforcement of the lifetime. What stops someone from registering an IScopedHttpClientFactory as a singleton or transient service?

If we want to cache/reuse the connection, it is enough to cache/reuse the bottom-most handler of the chain (aka PrimaryHandler). Other handlers in the chain may be re-instantiated for each unit-of-work scope, so they will have the correct instances of the scoped services injected into them (which is desired by customers).

I guess what makes this a bit unusual in that you want the ability to layer scoped decorators on top of singleton services. Both the singleton and scoped decorators need to implement what's functionally the same service interface, so we're not left with many options. [1] I would like to see an end-to-end example for how these scoped decorators would be defined and configured.

Service interfaces with a specific intended lifetime could be a good use case for a Roslyn analyzer. We could add attributes to service interfaces indicating what the intended lifetime is (if any) and warn if it's registered differently. We could do something similar for service implementations.

1: It would be nice if our DI system made decorating services easier in general. Today, you have to create custom interfaces/classes for registering the decorated type.

[CarnaViire]

You may see the actual implementation of IScopedHttpClientFactory in my PR here if that's what you were asking about @halter73

I agree, the naming pains me a little bit in a way you say, too. But I honestly couldn't come up with anything better, as the purpose of this service was to be scoped - to be able to provide scope where it's needed, opposed to singleton IHttpClientFactory.

But that's also touching on an interesting topic. If a person purposely refuses our default implementation by registering their own, in what way and how are we responsible for it?

If we are against allowing to substitute this one, we can always forbid it by registering via AddScoped instead of TryAddScoped, isn't that right?

[zmj]

+1 for the use case. I wanted to inject some request-scoped values into a delegating handler wrapping the base handler and didn't find a nice way to do that with the current configuration options for HttpClientFactory.

[CarnaViire]

Edit: Changed main proposal to be about transient HttpClientFactory as there's no need for an additional interface in this case. Moved IScopedHttpClientFactory to alternatives. Removed option with IServiceProvider parameter completely as it is both a bad practice and inconvenient to use.

[CarnaViire]

While discussing this API proposal we've found some additional complications.

Users that want to use PreserveExistingScope scenario might also want to set some Primary Handler parameters like MaxConnectionsPerServer or SslOptions at the same time, so we need to address that.

For users to be able to do that, we will need to separate configuring a primary handler from configuring the rest of the chain. Right now, all handlers configuration is stored in a single collection in HttpClientFactoryOptions:
IList<Action<HttpMessageHandlerBuilder>> HttpMessageHandlerBuilderActions

All handler configuration from methods like AddHttpMessageHandler and ConfigurePrimaryHttpMessageHandler is translated into actions on HttpMessageHandlerBuilder. This HttpMessageHandlerBuilder contains both a list of additional message handlers and a primary handler (to build a chain from them in the end). This way a chain is always created as a whole, but we want to be able to create the parts separately.

Additional API change no.1:
Separate primary handler changes in another place in HttpClientFactoryOptions. Add e.g.
IList<Action<HttpMessageHandlerBuilder>> PrimaryHttpMessageHandlerBuilderActions
or even
Function<IServiceProvider, HttpMessageHandler> PrimaryHttpMessageHandlerFactory.

After that, we want to put all primary handler changes into a new collection and additional handler changes into an old collection.

However, this separation is not straightforward. While AddHttpMessageHandler and ConfigurePrimaryHttpMessageHandler are easy, there are some APIs in HttpClientFactory that make it impossible to classify the changes. The APIs I'm speaking about are:

1. public static IHttpClientBuilder ConfigureHttpMessageHandlerBuilder(this IHttpClientBuilder builder, Action<HttpMessageHandlerBuilder> configureBuilder)
   (this one can be called upon HttpClient configuration)
   and
2. public interface IHttpMessageHandlerBuilderFilter with a method Action<HttpMessageHandlerBuilder> Configure(Action<HttpMessageHandlerBuilder> next);
   (for this, user can create their own implementation and register it in DI)

These both expose HttpMessageHandlerBuilder itself. As soon as any of these APIs are used, we can no longer decouple changes of the primary handler from changes of additional message handlers — because both of them may be changed in a single action.

That means we cannot support these APIs fully. There is no good way to treat them – see some options below:

Additional API change no.2:
The possible options are:

• Deprecate ConfigureHttpMessageHandlerBuilder and IHttpMessageHandlerBuilderFilter and replace them with new APIs to provide functionality of modifying the list of additional handlers (e.g. put a handler into a specific position in a list)
• Make ConfigureHttpMessageHandlerBuilder throw when per-request scope is enabled for HttpMessageHandlers - this doesn't fix IHttpMessageHandlerBuilderFilter problem
• Make PrimaryHandler modifications throw at runtime when per-request scope is enabled for HttpMessageHandlers
• Ignore any changes to PrimaryHandler – let the objects be allocated, but never used by us (we would overwrite it with the shared/cached primary handler)

Conclusion:
The combined API changes are quite extensive which is more than what we were planning for solving the initial issue. As a result, we are moving the proposal out of 6.0 to Future. We can reconsider the prioritization when there are more customers asking for this, or if we come up with better solution to the problem.