From 0c1a27af2e9071f52752c3959064eac3fc875f27 Mon Sep 17 00:00:00 2001 From: Natalia Kondratyeva Date: Fri, 16 Sep 2022 12:47:45 +0100 Subject: [PATCH 1/3] Fix HttpClient .NET Framework guidance --- .../fundamentals/networking/http/httpclient-guidelines.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/fundamentals/networking/http/httpclient-guidelines.md b/docs/fundamentals/networking/http/httpclient-guidelines.md index 5bfe6607732ea..d0970fef21b5d 100644 --- a/docs/fundamentals/networking/http/httpclient-guidelines.md +++ b/docs/fundamentals/networking/http/httpclient-guidelines.md @@ -28,14 +28,14 @@ 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. +'s 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. ## 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* 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 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. The factory pools instances, and, if its lifetime hasn't expired, a handler 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). +- In .NET Framework, use as proposed above. > [!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. From 242ceb15dc53a386e655fc06da19be6cbfc06f80 Mon Sep 17 00:00:00 2001 From: Natalia Kondratyeva Date: Fri, 16 Sep 2022 12:54:59 +0100 Subject: [PATCH 2/3] Fix trailing spaces --- docs/fundamentals/networking/http/httpclient-guidelines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/fundamentals/networking/http/httpclient-guidelines.md b/docs/fundamentals/networking/http/httpclient-guidelines.md index d0970fef21b5d..bc7f14f44e7a2 100644 --- a/docs/fundamentals/networking/http/httpclient-guidelines.md +++ b/docs/fundamentals/networking/http/httpclient-guidelines.md @@ -34,7 +34,7 @@ The preceding `HttpClient` is configured to reuse connections for 15 minutes. Af - 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. 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. The factory pools instances, and, if its lifetime hasn't expired, a handler 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). + - Using , you can have multiple, differently configured clients for different use cases. 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. The factory pools instances, and, if its lifetime hasn't expired, a handler 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). - In .NET Framework, use as proposed above. > [!TIP] From e7afef418e5b59fecc13e12e2c2f955d62b0d87e Mon Sep 17 00:00:00 2001 From: Genevieve Warren <24882762+gewarren@users.noreply.github.com> Date: Fri, 16 Sep 2022 10:59:29 -0700 Subject: [PATCH 3/3] Apply suggestions from code review --- .../networking/http/httpclient-guidelines.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/docs/fundamentals/networking/http/httpclient-guidelines.md b/docs/fundamentals/networking/http/httpclient-guidelines.md index bc7f14f44e7a2..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 -'s 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 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. 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. The factory pools instances, and, if its lifetime hasn't expired, a handler 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). -- In .NET Framework, use as proposed above. + - 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.