reject interleaved data frame in a fragmented websocket message

[arshsmith1]

What do these changes do?

WebSocketReader._handle_frame enforces RFC 6455 section 5.4 fragmentation only when a frame carries FIN. The not-fin branch appends the fragment and returns without checking whether a message is already in progress, so a new TEXT/BINARY frame with FIN cleared, sent between the opening fragment and its continuation, is silently merged into the message instead of failing the connection. The guard that rejects a non-continuation opcode mid-message is only reached for FIN=1 frames.

A spec-following peer or on-path proxy fails such a stream, so the reader assembles a message a compliant party would reject. This puts the same in-progress check on the not-fin branch, reusing the existing protocol-error path.

Are there changes in behavior for the user?

Only for the malformed case. A normal fragmented message (initial data fragment, continuation frames, interleaved control frames) is unaffected; a data frame arriving mid-message now closes with a protocol error, matching the FIN=1 handling already in place.

Is it a substantial burden for the maintainers to support this?

No. A few lines at the single frame-assembly site, with a regression test beside the existing continuation tests.

Related issue number

N/A

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes (N/A, no public API change)
• If you provide code modification, please add yourself to CONTRIBUTORS.txt
• Add a new news fragment into the CHANGES/ folder

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.02%. Comparing base (eb38b3c) to head (844f396).
⚠️ Report is 1 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #13553   +/-   ##
=======================================
  Coverage   99.02%   99.02%           
=======================================
  Files         135      135           
  Lines       50455    50461    +6     
  Branches     2647     2648    +1     
=======================================
+ Hits        49962    49968    +6     
  Misses        370      370           
  Partials      123      123           

Flag	Coverage Δ
Autobahn	22.03% <14.28%> (-0.01%)	⬇️
CI-GHA	98.91% <100.00%> (+<0.01%)	⬆️
OS-Linux	98.69% <100.00%> (-0.01%)	⬇️
OS-Windows	97.08% <71.42%> (-0.01%)	⬇️
OS-macOS	97.97% <71.42%> (+<0.01%)	⬆️
Py-3.10	98.11% <100.00%> (+<0.01%)	⬆️
Py-3.11	98.35% <100.00%> (+<0.01%)	⬆️
Py-3.12	98.43% <100.00%> (+<0.01%)	⬆️
Py-3.13	98.42% <100.00%> (+<0.01%)	⬆️
Py-3.14	98.45% <100.00%> (+<0.01%)	⬆️
Py-3.14t	97.62% <71.42%> (+<0.01%)	⬆️
Py-pypy-3.11	97.41% <100.00%> (+<0.01%)	⬆️
VM-macos	97.97% <71.42%> (+<0.01%)	⬆️
VM-ubuntu	98.69% <100.00%> (-0.01%)	⬇️
VM-windows	97.08% <71.42%> (-0.01%)	⬇️
cython-coverage	83.09% <85.71%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

Merging this PR will not alter performance

✅ 94 untouched benchmarks
⏩ 83 skipped benchmarks¹

---

_{Comparing arshsmith1:ws-reject-interleaved-data-frame (844f396) with master (eb38b3c)²}

Footnotes

1. 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. ↩

2. No successful run was found on master (4047e5b) during the generation of this report, so eb38b3c was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩