Allow proxy middleware to abort long running connections. #784

Closed
opened 2025-08-09 17:17:40 +00:00 by fergalmoran · 0 comments
Owner

Originally created by @mattvperry on 5/4/2017

The conditional proxy middleware that is used for connecting to the webpack dev server was leaving lingering connections when proxying long-running HTTP requests like those used for hot reloading.

This was happening because the CancellationTokenSource which lives on the HttpContext was never getting called after the initial SendAsync which completes after headers are sent.

The fix is simply to ensure that we respect the cancellation token when copying from the upstream response.

Note: I noticed this because when using .Net 4.6 plus System.Net.Http >= 4.3.1, you can only have 2 concurrent HttpClient requests active at a time because this change: dotnet/corefx#15036 uses the HttpClientHandler.MaxConnectionsPerServer with a default of 2. What was happening was that if I reloaded the page once or twice the hot module reloading wouldn't connect to webpack because it wouldn't let any more connections through because there were a couple lingering threads. It also might be worth changing HttpClientHandler.MaxConnectionsPerServer to something higher because even with this change the connections don't close immediately so several quick reloads can get you in the same position. Picking that default concurrency was out of scope for this PR though, I felt.

*Originally created by @mattvperry on 5/4/2017* The conditional proxy middleware that is used for connecting to the webpack dev server was leaving lingering connections when proxying long-running HTTP requests like those used for hot reloading. This was happening because the `CancellationTokenSource` which lives on the `HttpContext` was never getting called after the initial `SendAsync` which completes after headers are sent. The fix is simply to ensure that we respect the cancellation token when copying from the upstream response. Note: I noticed this because when using .Net 4.6 plus System.Net.Http >= 4.3.1, you can only have 2 concurrent `HttpClient` requests active at a time because this change: dotnet/corefx#15036 uses the `HttpClientHandler.MaxConnectionsPerServer` with a default of 2. What was happening was that if I reloaded the page once or twice the hot module reloading wouldn't connect to webpack because it wouldn't let any more connections through because there were a couple lingering threads. It also might be worth changing `HttpClientHandler.MaxConnectionsPerServer` to something higher because even with this change the connections don't close immediately so several quick reloads can get you in the same position. Picking that default concurrency was out of scope for this PR though, I felt.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/JavaScriptServices#784
No description provided.