Hardcopy

The Problem: Understanding AddHttpClient and Its Lifecycle

In .NET, HttpClient is typically registered using the AddHttpClient extension method in IServiceCollection. This method registers an IHttpClientFactory, which manages the lifecycle of HttpClient instances.

When you request an HttpClient instance from the factory, it doesn't create a completely new client. Instead, it reuses an HttpMessageHandler from an internal pool to improve performance and reduce socket exhaustion. The HttpMessageHandler is what actually manages the underlying HTTP connections, and it is only recreated after a defined lifetime (default is 2 minutes).

How the Underlying HttpMessageHandler Works

The HttpMessageHandler is responsible for:

• Managing the actual network connection to the server
• Handling cookies, authentication headers, and connection pooling
• Keeping sockets open for reuse to improve performance

Because HttpClient instances created by the factory reuse the same HttpMessageHandler (until it is recycled), any stateful aspects of the handler—such as cookies—can persist across requests, even for different HttpClient instances.

What This Means: Cookies Can Be Shared Across Calls

Since HttpMessageHandler persists across HttpClient instances, any cookies set by a server during a request can be shared between different calls, even if they come from separate HttpClient instances.

This can lead to unintended behavior, such as:

• User sessions being unintentionally shared across API calls
• Authentication issues where a previous session is reused unexpectedly
• Unexpected behavior in multi-tenant applications where requests for different tenants could carry over session state

How to Fix It: Explicitly Disable Cookies

To prevent HttpMessageHandler from storing and reusing cookies, you must explicitly disable cookie handling. This can be done by configuring HttpClientHandler when setting up the HttpClientFactory:

services.AddHttpClient("NoCookiesClient")
    .ConfigurePrimaryHttpMessageHandler(() =>
    {
        return new HttpClientHandler
        {
            UseCookies = false
        };
    });

Explanation:

• ConfigurePrimaryHttpMessageHandler allows customization of the HttpMessageHandler used by HttpClient.
• Setting UseCookies = false ensures that cookies are not stored or reused between requests.

With this configuration, each request will behave as if it has no prior session, preventing cookie leakage across different requests.

Conclusion

While HttpClientFactory improves performance by reusing HttpMessageHandler, it can introduce issues with shared state, especially cookies. By explicitly disabling cookies in HttpClientHandler, you can ensure each request is isolated and prevent unintended session sharing.

I recently needed to access a database with EF Core from a console application.

I used the EF Core Tools to accomplish this. First install the EF Core Tools, run this command in the Package Manger Console:

Install-Package Microsoft.EntityFrameworkCore.Tools

Once you have the required tools installed you can scaffold the DbContext and enties using the following command. Substitute the database details and required tables:

Scaffold-DbContext "Server=SERVER;Database=DATABASE;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer -OutputDir Models -Tables TABLE_1, TABLE_2 -Context Context -Force

The -Force flag will overwrite any existing files. This is useful if you want to add an extra table later on. Keep in mind you will need to specify all the tables the second time. The process will not update the context, but rather overwrite it. So if you miss any tables the second time you will be unable to use them.

Another option which I think is quite useful is the ContextDir flag, this allows you to specify an alternative location for the DbContext, by default this class will be located along with the Models/Entites.