Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add HttpClient.Shared #84327

Closed
wants to merge 1 commit into from
Closed

Conversation

stephentoub
Copy link
Member

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.

@stephentoub stephentoub added this to the 8.0.0 milestone Apr 4, 2023
@dotnet-issue-labeler
Copy link

Note regarding the new-api-needs-documentation label:

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
Copy link

ghost commented Apr 4, 2023

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

Issue Details

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.

Author: stephentoub
Assignees: -
Labels:

area-System.Net.Http

Milestone: 8.0.0

{
// 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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes me feel better about this feature.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a fan of getter's throwing, I'd rather return a read-only object that threw if you tried to modify it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@antonfirsov antonfirsov Apr 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we want to do the same in CancelPendingRequests(), and any other member that has a chance to mess with independent callers?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@davidfowl
Copy link
Member

Do you think the inability to add message handlers is a problem?

@stephentoub
Copy link
Member Author

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.

@Symbai
Copy link

Symbai commented Apr 5, 2023

all I want to do is grab some data from something on the web, and this makes it a one-liner.

And what does

await HttpClient.Shared.GetStringAsync("https://dot.net/somefile.txt");

makes any better than:

await new HttpClient().GetStringAsync("https://dot.net/somefile.txt");

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.

@stephentoub
Copy link
Member Author

And what does
await HttpClient.Shared.GetStringAsync("https://dot.net/somefile.txt");
makes any better than:
await new HttpClient().GetStringAsync("https://dot.net/somefile.txt");

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.

@Symbai
Copy link

Symbai commented Apr 5, 2023

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.

@stephentoub
Copy link
Member Author

stephentoub commented Apr 5, 2023

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.

@MSDN-WhiteKnight
Copy link
Contributor

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;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 stephentoub added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label Apr 14, 2023
@stephentoub
Copy link
Member Author

I still think this is valuable, but there's enough consternation over this that I'm going to close it.

@stephentoub stephentoub deleted the httpclientshared branch April 15, 2023 13:38
@ghost ghost locked as resolved and limited conversation to collaborators May 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Net.Http new-api-needs-documentation NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants