Repository navigation
Port exhaustion regression #198
Description
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.
Activity
SchlenkR commentedon Sep 9, 2024
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:
httpClientHandlerTransformersandhttpClientTransformersas 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.SchlenkR commentedon Mar 9, 2026
/repo-assist Could you comment on this in general? Backward-compatibility is important here...
github-actions commentedon Mar 9, 2026
fix: reuse SocketsHttpHandler to prevent SNAT port exhaustion (closes #…
github-actions commentedon Mar 10, 2026
🤖 This is an automated response from Repo Assist.
Following up on my earlier analysis: I've submitted a draft PR that implements the fix described as "Option 1" — a process-wide lazy singleton
SocketsHttpHandlerfor the default configuration.The key change is in
Defaults.fs: the default factory now returns a shared handler (withdisposeHandler=false) when no proxy, custom handler transformers, or non-default cert/decompression settings are in play. Each request still gets its ownHttpClientwrapper, so per-requestTimeoutandhttpClientTransformerscontinue to work unchanged. Custom factory configurations are unaffected.Please take a look at the PR and let me know if the approach looks good or if you'd prefer a different design.