microsoft
Semantic Kernel needs a consistent story around HttpClient
Some types create and destroy their own HttpClient{Handler} instances, which could lead to poor performance and port exhaustion if done too frequently.
Some types optionally allow an HttpClient to be supplied, constructing a new HttpClient with a new HttpClientHandler if one isn't.
Some types optionally allow an HttpClientHandler to be supplied, constructing a new HttpClientHandler if one isn't.
Some types optionally allow an HttpClient to be supplied, constructing a new HttpClient with a shared singleton HttpClientHandler if one isn't.
Etc.
We should be consistent across all of Semantic Kernel, and in situations where a client/handler isn't supplied, we should ensure we're using as few HttpClientHandler instances as possible.
@stephentoub does #743 take care of this or do we still have some remnants laying around?
@SergeyMenshykh is still rolling out a more consistent story. He's been working his way through all the components in the repo. Happy for him to close this when he's ready.
Closing the issue since all SK components have been modified to work with either external instance of HttpClient or the internal one, which is created by default if no external instance is provided.
