Skip to content

Reuse HttpClient and HttpClientHandler in Web Cmdlets #6156

Closed

Description

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

Activity

  1. changed the title [-]Reuse HttpClient and HttpClientHandler[/-] [+]Reuse HttpClient and HttpClientHandler in Web Cmdlets[/+] on Feb 14, 2018
  2. markekraus commented on May 11, 2018

    @markekraus
    ContributorAuthor

    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.

  3. CarloToso commented on Mar 15, 2023

    @CarloToso
    Contributor

    Ilya (@iSazonov) Should be fixed in PS 7.4.0 preview2 by #19249 (comment) (maybe we should add some documentation)

  4. iSazonov commented on Mar 16, 2023

    @iSazonov
    Collaborator

    Dup #9977.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-Enhancementthe issue is more of a feature request than a bugResolution-DuplicateThe issue is a duplicate.WG-Cmdletsgeneral cmdlet issues

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions