Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.98%. Comparing base (4ae5d49) to head (184eac6).
⚠️ Report is 14 commits behind head on master.
✅ All tests successful. No failed tests found.

@@           Coverage Diff           @@
##           master   #13271   +/-   ##
=======================================
  Coverage   98.98%   98.98%           
=======================================
  Files         131      132    +1     
  Lines       48993    49020   +27     
  Branches     2550     2552    +2     
=======================================
+ Hits        48496    48523   +27     
  Misses        373      373           
  Partials      124      124           

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

Merging this PR will not alter performance

✅ 84 untouched benchmarks
⏩ 83 skipped benchmarks¹

_{Comparing LuShadowX:parser-parity-tests (184eac6) with master (b2b7b50)}

@Dreamsorcerer this is the parity pass you suggested on #13246 — the three inputs both parsers reject are now parametrised over both, and the lowercase-method case that only they differ on has a C-side test next to the Python one. Tests only, no parser changes.

I'm not sure why new tests are being added, rather than fixing existing ones.

Fair point — reworked in 184eac6 so the PR now only widens existing tests and adds none.

Converted:

• test_unpaired_surrogate_in_header_py → test_unpaired_surrogate_in_header, on the parser fixture. Expectations stay implementation-specific: InvalidHeader for the Python parser, BadHttpMessage for llhttp.
• test_py_parser_normalises_method_to_uppercase → test_lowercase_method, likewise. The Python parser canonicalises the token, llhttp raises BadHttpMethod.

Dropped both of the ones that were genuinely new rather than parity work: control characters in a header value are already covered for both parsers by test_ctl_host_header_bad_characters, and the bare-LF case is the divergence below.

One thing worth a decision separately. test_invalid_linebreak is C-only, and it has to stay that way, because the Python parser does not reject its input:

py  | GET /world HTTP/1.1\r\nHost: 127.0.0.1\n\r\n  | no exception, no messages
c   | GET /world HTTP/1.1\r\nHost: 127.0.0.1\n\r\n  | BadHttpMessage

A bare LF terminating a header line leaves the Python parser waiting for more data instead of failing. Move the LF into the middle of the header block — Host: a\nX-Evil: b\r\n\r\n — and it does raise InvalidHeader, so it is specifically the header-terminating position that slips through. RFC 9112 §2.2 wants a bare LF rejected there, and it is the kind of gap that matters for request smuggling, so I would rather raise it as its own issue than bury it in a test-parity PR. Want me to open one?

Verified locally with the C extension built: 839 passed, 3 xfailed on tests/test_http_parser.py, and 427 passed, 34 skipped under AIOHTTP_NO_EXTENSIONS=1. mypy and black clean on the file — the module check in _is_py_parser is there because HttpRequestParserPy aliases the class the annotations name, so isinstance() makes the negative branch statically unreachable.

The one red check isn't the code — Backport label added is a gate that exits 1 unless the PR carries a label starting with backport, and this one only has bot:chronographer:provided. #13246 passes because it has backport-3.14 and backport-3.15.

I can't set labels here, and which one applies is your call: backport:skip, or backport-3.14/backport-3.15 if you want the parity coverage on the release branches too.