You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Reuse HttpClient and HttpClientHandler in Web Cmdlets #6156
HttpClient and HttpClientHandler, while implementing IDisposable, are intended to be reused. not re using HttpClient results in significant overhead and loses out on the ability to reuse TCP pools. We currently create and dispose HttpClient and HttpClientHandler instances on every call to the web cmdlets. With large numbers of HTTP requests this can get expensive.
We should investigate the introduction of a single HttpClient/HttpClientHandler. One of my specific concerns is that it may not play nicely in multi-threading scenarios. a static instance of these is supposed ot be thread safe, but, I have no clue if a change in one thread to HttpClientHandler.Credentials (for example) will have an impact on the handler in another thread. *shrugs
I have done some research into this, and it appears to not be possible with HttpClientHandler.
We allow the user to supply options which are used to generate a HttpClientHandler with their options. There is an inseparable bond between an instance of HttpClient and HttpClientHandler, so you cannot change the handler once the client is instantiated. That means we'd need a singleton of both for each thread to prevent changes in one thread polluting another. This is achievable with ThreadLocal<T>. However, once you make a request with HttpClient all of the settings on the HttpClientHandler become locked and you are unable to make any changes to any of the properties on the instance. That means that if the user were to supply -SkipCertificateCheck and we applied it on the first request, we would be unable to set HttpClientHandler.ServerCertificateCustomValidationCallback to null for a subsequent request.
Effectively, creating and disposing HttpClient and HttpClientHandler on every call to IWR/IRM as we currently do is all we can do with those APIs.
It may be possible to use HttpMessageHandler to construct our own HttpClientHandler replacement, but we may end up with some re-inventing the wheel.
I have a very real concern that we could see connection/socket exhaustion issues with PowerShell scripts that make high volume calls to the Web Cmdlets, but those would be extreme uses and outliers. As such, I'll hold off on further work on this until the need arises.
Activity
[-]Reuse HttpClient and HttpClientHandler[/-][+]Reuse HttpClient and HttpClientHandler in Web Cmdlets[/+]markekraus commentedon May 11, 2018
I have done some research into this, and it appears to not be possible with
HttpClientHandler.We allow the user to supply options which are used to generate a
HttpClientHandlerwith their options. There is an inseparable bond between an instance ofHttpClientandHttpClientHandler, so you cannot change the handler once the client is instantiated. That means we'd need a singleton of both for each thread to prevent changes in one thread polluting another. This is achievable withThreadLocal<T>. However, once you make a request withHttpClientall of the settings on theHttpClientHandlerbecome locked and you are unable to make any changes to any of the properties on the instance. That means that if the user were to supply-SkipCertificateCheckand we applied it on the first request, we would be unable to setHttpClientHandler.ServerCertificateCustomValidationCallbackto null for a subsequent request.Effectively, creating and disposing
HttpClientandHttpClientHandleron every call to IWR/IRM as we currently do is all we can do with those APIs.It may be possible to use
HttpMessageHandlerto construct our ownHttpClientHandlerreplacement, but we may end up with some re-inventing the wheel.I have a very real concern that we could see connection/socket exhaustion issues with PowerShell scripts that make high volume calls to the Web Cmdlets, but those would be extreme uses and outliers. As such, I'll hold off on further work on this until the need arises.
CarloToso commentedon Mar 15, 2023
Ilya (@iSazonov) Should be fixed in PS 7.4.0 preview2 by #19249 (comment) (maybe we should add some documentation)
iSazonov commentedon Mar 16, 2023
Dup #9977.