Handle ERROR_CONNECTION_INVALID after ERROR_MORE_DATA #36146
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wtgodbe
approved these changes
Sep 3, 2021
Member
Author
|
/backport to release/6.0 |
Contributor
|
Started backporting to release/6.0: https://github.com/dotnet/aspnetcore/actions/runs/1198835265 |
amcasey
added
area-networking
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Fixes #35892
6.0-rc2 candidate.
HttpSys uses 4kb buffers to dequeue requests from the native queue. When a request is too large HttpReceiveHttpRequest returns ERROR_MORE_DATA with the real size, we allocate a new buffer and call HttpReceiveHttpRequest again with the specific request id.
Problem: The client can disconnect between the two calls to HttpReceiveHttpRequest. In that case the second call to HttpReceiveHttpRequest will return ERROR_CONNECTION_INVALID. This wasn't an expected error code so it bubbled up the stack and got logged at the Error level. The server tried again and remained healthy so the issue is only log noise.
This is a 6.0 candidate because unexpected Error level logs automatically trigger investigations for partner services.
There's no unit test for this because it's a very tight race condition and once it's handled there are no observable affects. See #35892 (comment) for the manual repro instructions.