[feiiiiii5]

What is wrong

content-length was only enforced when a DATA frame arrived. If END_STREAM was on the HEADERS block, or on a trailers block, the zero-length body skipped _track_content_length(), so a message could declare content-length: 5 and send no body at all. A trailers block containing its own content-length also overwrote the expected length from the header block.

POST content-length: 5 + END_STREAM on trailers  -> accepted
200  content-length: 5 + END_STREAM on HEADERS   -> accepted

What changes

• A trailers block no longer calls _initialize_content_length(); content-length belongs to the header block.
• When END_STREAM arrives on a header or trailers block, the zero-length body is validated against the expected length. HEAD, 204 and 304 keep their zero-length exemption from _initialize_content_length().
• A matching body followed by trailers is still accepted.

Tests

tests/test_content_length_end_stream.py covers a request with END_STREAM on trailers, the same request with the declared body then trailers, a response with END_STREAM on HEADERS, and a response with no content-length. The two rejection cases fail on the parent revision; the full h2 suite is 1666 passed. ruff check src/ and mypy --strict src/h2/stream.py pass.

[Kriechi]

How does this PR related to your other PR #1329?

[feiiiiii5]

Thanks for asking — they do overlap on one path and I should have said so in the description.

• Shared with Validate content-length when a stream ends with trailers #1329: the trailers branch. Both call _track_content_length(0, end_stream=True) when a trailers block arrives with END_STREAM, because that is the only point where a body that ends in trailers can be policed. Validate content-length when a stream ends with trailers #1329 goes further there: it also rejects a content-length appearing in a trailer section at all (_reject_content_length_in_trailers in validate_headers), whatever its value.
• Only here: END_STREAM on the header block. content-length: 5 with no DATA at all was accepted, since _track_content_length was reachable only from receive_data. Validate content-length when a stream ends with trailers #1329 does not touch that case.

So as written this branch is a superset on the trailers side and adds the header-block side. Two clean shapes, and it is your call:

1. Keep Validate content-length when a stream ends with trailers #1329 as the trailers work and rebase this one onto it so it carries only the header-block hunk plus its test — one small diff to review, and the two together still cover every way a stream can end.
2. Close this and fold the header-block case into Validate content-length when a stream ends with trailers #1329, which already has the harness and the test_invalid_content_lengths.py file.

I would lean to 1, since #1329 has already been reviewed on its own terms and would have to be re-read otherwise. I will not push anything here until you say which you prefer.