reject reserved close code 1006 in websocket reader - #13536
Open
arshsmith1 wants to merge 1 commit into
Open
Conversation
psf-chronographer
Bot
added
the
bot:chronographer:provided
arshsmith1
force-pushed
the
ws-reject-reserved-close-code
branch
from
August 24, 2026 07:06
4d003f2 to
5a050bf
Compare
Confidence Score: 5/5The PR appears safe to merge with no actionable correctness, security, or compatibility issues identified. Incoming code 1006 is now rejected at the existing close-code validation boundary without changing locally generated abnormal-closure handling. Reviews (1): Last reviewed commit: "reject reserved close code 1006 in webso..." | Re-trigger Greptile |
❌ 2 Tests Failed:
View the full list of 2 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
Merging this PR will degrade performance by 14.86%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ❌ | test_list_element_pattern_redos_payload[whitespace_run_after_content] |
28.3 ms | 33.3 ms | -14.86% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing arshsmith1:ws-reject-reserved-close-code (5a050bf) with master (fdebfa2)
Footnotes
-
83 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
A
Closeframe's status code is checked inWebSocketReader._handle_frameagainstALLOWED_CLOSE_CODES, a set built from theWSCloseCodeenum. The enum carriesABNORMAL_CLOSURE(1006), which aiohttp only sets locally when a connection drops without a Close frame, so a frame that arrives with1006on the wire passed the check and was delivered as a valid close code (and could be echoed back in aiohttp's own close frame). RFC 6455 7.4.1 reserves1006, along with1005and1015, and forbids it as a status code on the wire, so1006is now rejected as a protocol error the same way1005and1015already are.What do these changes do?
Exclude
ABNORMAL_CLOSUREfrom the incoming-frame acceptance set so a Close frame carrying1006fails with a protocol error.1005and1015were already rejected because they are not enum members; only1006slipped through.Are there changes in behavior for the user?
Only for the malformed case. A peer that sends
1006in a Close frame now trips a protocol error instead of surfacing as a close message. The locally-generated1006for an abnormal closure (no Close frame received) is unchanged.Is it a substantial burden for the maintainers to support this?
No. It drops one reserved code from the acceptance set and adds a regression test beside the existing close-code tests.
Related issue number
None.
Checklist
CONTRIBUTORS.txt(already listed)CHANGES/folder