diff --git a/docs/fundamentals/networking/http/httpclient-guidelines.md b/docs/fundamentals/networking/http/httpclient-guidelines.md index 5bfe6607732ea..30dc102f5b253 100644 --- a/docs/fundamentals/networking/http/httpclient-guidelines.md +++ b/docs/fundamentals/networking/http/httpclient-guidelines.md @@ -28,14 +28,18 @@ The preceding `HttpClient` is configured to reuse connections for 15 minutes. Af ## Pooled connections -In .NET Framework, disposing objects does not impact connection management. However, in .NET Core, the connection pool is linked to the client's underlying . When the instance is disposed, it disposes all previously used connections. If you later send a request to the same server, a new connection is created. There's also a performance penalty because it needs a new TCP port. If the rate of requests is high, or if there are any firewall limitations, that can **exhaust the available sockets** because of default TCP cleanup timers. +The connection pool for an is linked to its underlying . When the instance is disposed, it disposes all previously used connections. If you later send a request to the same server, a new connection is created. There's also a performance penalty because it needs a new TCP port. If the rate of requests is high, or if there are any firewall limitations, that can **exhaust the available sockets** because of default TCP cleanup timers. ## Recommended use -- In .NET Framework, create a new each time you need to send a request. - In .NET Core and .NET 5+: - - Use a static or singleton with set to the desired interval, such as two minutes, depending on expected DNS changes. This solves both the socket exhaustion and DNS changes problems without adding the overhead of . If you need to be able to mock your handler, you can register it separately. - - Using , you can have multiple, differently configured clients for different use cases. If its lifetime hasn't expired, an instance may be reused from the pool when the factory creates a new instance. This reuse avoids any socket exhaustion issues. If you desire the configurability that provides, we recommend using the [typed-client approach](../../../core/extensions/httpclient-factory.md#typed-clients). However, be aware that the clients created by the factory are intended to be short-lived, and once the client is created, the factory no longer has control over it. + - Use a `static` or *singleton* instance with set to the desired interval, such as two minutes, depending on expected DNS changes. This solves both the socket exhaustion and DNS changes problems without adding the overhead of . If you need to be able to mock your handler, you can register it separately. + - Using , you can have multiple, differently configured clients for different use cases. However, be aware that the factory-created clients are intended to be short-lived, and once the client is created, the factory no longer has control over it. + + The factory pools instances, and, if its lifetime hasn't expired, a handler can be reused from the pool when the factory creates a new instance. This reuse avoids any socket exhaustion issues. + + If you desire the configurability that provides, we recommend using the [typed-client approach](../../../core/extensions/httpclient-factory.md#typed-clients). +- In .NET Framework, use to manage your `HttpClient` instances. If you create a new client instance for each request, you can exhaust available sockets. > [!TIP] > If your app requires cookies, consider disabling automatic cookie handling or avoiding . Pooling the instances results in sharing of objects. Unanticipated object sharing often results in incorrect code.