GeezerVison

What this fixes

A 304 or 204 response carrying a non-zero content-length was accepted when the response ended with END_STREAM on HEADERS but rejected with InvalidBodyLengthError when it ended with an empty DATA frame. Separately, a message that ends on HEADERS with END_STREAM never had its declared content-length checked at all, so a bogus 200 response with content-length: 1234 and no body was accepted.

RFC 9113 § 8.1.1 defines 204, 304 and the response to HEAD as having no content, and RFC 9110 § 8.6 says such a message may carry a non-zero content-length. The implementation only exempted HEAD, and only the DATA framing ran _track_content_length(0, end_stream=True).

Fixes #1330.

Changes

• _initialize_content_length: recognize :status: 204 and :status: 304 the same way as HEAD — set _expected_content_length = 0; a non-zero content-length is allowed, and non-empty DATA is still rejected.
• receive_headers: when a non-trailers HEADERS block ends the stream, run the same _track_content_length(0, end_stream=True) bookkeeping as an empty DATA END_STREAM. 204/304/HEAD pass; a normal response whose content-length does not match its body is now rejected under either framing.
• Add eight regressions in tests/test_invalid_content_lengths.py: 204/304 with content-length ending on HEADERS and on empty DATA, 204/304 with non-empty DATA, and 200/POST with a lying content-length ending on HEADERS.
• The #1328 trailers behavior and the other smaller items in A 304 with content-length is accepted or rejected by framing alone #1330 are intentionally out of scope.

Testing

• Red on the old code: PYTHONPATH=src python3 -m pytest tests/test_invalid_content_lengths.py -q -> 6 failed, 27 passed.
• Green after the fix: same command -> 33 passed; full suite -> 1692 passed.
• Coverage: coverage run --branch --source=src/h2 -> 100% (1919 statements, 470 branches, 0 missed) — the repository's fail_under=100 gate stays satisfied.
• mypy src/h2/stream.py, ruff check src/h2/stream.py and git diff --check pass.