Port exhaustion regression

[ntwilson]

Using FsHttp with the default httpClientFactory on an Azure Web App to send many HTTP requests to the same domain results in SNAT port exhaustion, with the error

System.Net.Sockets.SocketException (10060): A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

From what I can tell, this is because the default factory will create a new HttpClient instance for each request. Microsoft documentation states that if you are not using HttpClientFactory with DI, you should have a singleton HttpClient for the lifetime of your application to avoid the port exhaustion problem.

It looks like this problem was fixed in #37, but then reintroduced later.

[SchlenkR]

Thank you very much for submitting this issue. The problem here is that FsHttp allows per-request configuration of the underlying SocketsHttpHandler, which then results in a per-request instance of HttpClient. We could think about something like:

• mark the per-instance httpClientHandlerTransformersand httpClientTransformers as obsolete, and change the behavior of the request generation in a way that if they are not used for a request, a per-process instance of the related SocketsHttpHandler, HttpClient, etc. are used.
• allow a per-process default configuration of these 2 transformers.