[release/10.0] (http2): Lower WINDOWS_UPDATE received on (half)closed stream to stream abortion #63885
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #63873 to release/10.0
(http2): Lower WINDOWS_UPDATE received on (half)closed stream to stream abortion
Change affects the server HTTP/2 behavior in the case client sends the RST_STREAM frame (moving stream to half-closed or closed state) and then sends another packet - WINDOW_UPDATE. Server behavior varies in this case (RFC HTTP/2 does not describe this case extremely clear) - for example HTTP.SYS does interpet this as a stream-level error (ignore of WINDOW_UPDATE packet); but Kestrel is more strict and sends the GO_AWAY packet closing not only the stream, but also the whole connection.
Such restrictive behavior of Kestrel impacts the client, which observes cancellations and has to re-establish the connection frequently.
Fixes #63726
Customer Impact
1P Customer which processes intensive traffic of another 1P customer with a Golang-based client observes high volume of cancellations. This not only impacts the performance where a new connection has to be established, but also means all streams existing on the connection were lost, resulting in bunch of customers seeing high latency.
Regression?
Risk
Small change in behavior making Kestrel less restrictive. Also is being tested by the 1P team.
Verification
Packaging changes reviewed?
When servicing release/2.3