-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[release/6.0] Respect the Keep-Alive response header on HTTP/1.0 #73245
[release/6.0] Respect the Keep-Alive response header on HTTP/1.0 #73245
Conversation
* Respect the Keep-Alive response header on HTTP/1.0 * Remove TimeoutOffset * Update Trace message * Update tests * Adjust test timeouts
Tagging subscribers to this area: @dotnet/ncl |
This PR has been pre-approved for 6.0.9 by Tactics today, pending final agreement with @stephentoub. |
Update: We have reached consensus over email with @stephentoub and decided to take this change into 7.0 and 6.0.x servicing. Removing the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tactics approved.
Correct milestone applied.
No CI failures.
No OOB package authoring needed (System.Net.Http.csproj does not have <IsPackable>
).
Signed off by area owner.
Ready to merge!
Backport of #73020 and #73585
Fixes #72958
Customer Impact
There is an inherent race in HTTP/1.x between the server closing an idle connection and the client trying to send a request at the same time (#60644). To mitigate this, the server may respond with a
Keep-Alive: timeout=60
header that informs the client of how long it can reuse an idle connection for.This change makes
SocketsHttpHandler
look for this header and use it to limit the idle timeout of a connection.As a result, we avoid the race condition and fewer requests fail with a "Connection reset by peer" error.
Testing
Targeted test cases have been added and the patch was validated by an internal party in production.
Risk
There is a tradeoff between mitigating the race condition and how long we consider an idle connection usable for.
There is a risk that the user may see more connections being established if they make requests on an interval that falls within a 1-second offset of the server Keep-Alive timeout.
For example, if the server responds with a timeout of 5 seconds and the user has a script pinging the server every 4.5 seconds, every request would create a new connection instead of reusing the existing one.
Users facing such an issue can increase the interval at which they make requests or if possible increase the timeout on the server.