Add HttpClient.Shared #84327
Add HttpClient.Shared #84327
Conversation
|
Note regarding the This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change. |
ghost
assigned 
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsAdds the static HttpClient.Shared property. @dotnet/ncl, I'm waffling on whether we actually want to add this:
|
| { | ||
| // HttpRequestHeaders is not thread safe. Developers trying to mutate HttpClient.Shared.DefaultRequestHeaders | ||
| // could thus corrupt the instance if used from multiple threads. | ||
| throw new NotSupportedException(SR.net_http_shared_httpclient_notsupported); |
There was a problem hiding this comment.
This makes me feel better about this feature.
There was a problem hiding this comment.
Not a fan of getter's throwing, I'd rather return a read-only object that threw if you tried to modify it.
There was a problem hiding this comment.
I'd rather return a read-only object that threw if you tried to modify it.
That would a) make HttpRequestHeaders slower for everyone and b) not really affect anything because it has getters that mutate (e.g. lazily instantiate) and they would then need to throw instead.
There was a problem hiding this comment.
Don't we want to do the same in CancelPendingRequests(), and any other member that has a chance to mess with independent callers?
There was a problem hiding this comment.
Don't we want to do the same in CancelPendingRequests(), and any other member that has a chance to mess with independent callers?
We could. CancelPendingRequests is "safe" to use concurrently, whereas DefaultRequestHeaders is not, hence why I gave the latter this treatment.
|
Do you think the inability to add message handlers is a problem? |
This is for simple situations where you're just doing "new HttpClient().GetStringAsync()` today, only this lets you do it better. For anything where you need to configure anything, this isn't for you. As I raised in API review today, if we think that's a problem, we shouldn't add it, but it also makes the simple cases simpler and more streamlined. So many times when I'm writing a little tool or a benchmark or a demo or whatever, all I want to do is grab some data from something on the web, and this makes it a one-liner. |
And what does
makes any better than:
in terms of line count?! If my eyes are working correctly the amount of lines should be equal in both cases. If its the performance, you would rather create a single static httpclient you reuse (which is what is also recommended by the documentation). And this one you can also customize the way you want, if you want. But for these "small tools" you mention I doubt that performance matters at all. If you just grab something from the web, in a small tool, for a single or second time you aren't even forced to dispose the HttpClient because in real world these few bytes are not killing any machine. But if performance matters and you need to dispose the client, because it's getting called frequently. Then you'd rather do what the documentation recommends you to do. |
It makes it better when you on the very next line do the same thing but for a different file, or you do this in a loop, or some such thing. It makes it better when you do this in a few different places. It makes it better in that you're not instantiating an HttpClient and thus not on the hook to track and clean up after it. |
Sounds great but isn't that exactly what I mentioned before? When this is important for your app, create a static readonly httpclient and use that. The docs even say so. But if that is not important which I expected when you said "its for small apps doing small things", then I still don't see how it makes it any better. It feels like its just there for "completeness". Just for having it there. But it doesn't feel like there is a real need for this. Or a real world scenario. Or it solves a real problem. |
|
It's about making something that lots of folks need to do even easier, with greater liklihood for shared resources. If you have a helper over here that needs to grab some data, and another over there, and another over there, they don't each need to manage their own separate client or deal with DI complexities. And if you're making multiple calls even in the same component, you don't have to create a static readonly or even know you're supposed to. Simple things stay simple. |
|
It looks simple, but there's a hidden complexity. The proposed API is good for small apps, but you can't ensure that developers of larger apps get it right. For example, current guidelines for HttpClient recommend using singleton instance with PooledConnectionLifetime property set to some value, to avoid stale DNS usage: https://learn.microsoft.com/en-us/dotnet/fundamentals/networking/http/httpclient-guidelines#recommended-use How this issue will be solved with proposed API? If the new shared instance just uses default behaviour, with endless connection lifetime, it will be easy for people to run into exactly this issue. Some way to configure connection pooling behaviour is really needed. |
| _disposed = true; | ||
| if (_isSharedInstance) | ||
| { | ||
| return; |
There was a problem hiding this comment.
As we're not disposing the client, we might see more issues with H/3 similar to this: #71927
The problem is that without Dispose, msquic might not send the last frames before exiting the app, causing problems on the other side, e.g. missing ACKs causing hangs.
stephentoub
added
the
NO-MERGE
|
I still think this is valuable, but there's enough consternation over this that I'm going to close it. |
Adds the static HttpClient.Shared property.
@dotnet/ncl, I'm waffling on whether we actually want to add this:
#65380 (comment)
but if we do, here we go.