GeezerVison

What is wrong

RFC 9113 § 8.1.1 defines 204, 304 and the response to HEAD as messages that have no content, and says such a message may carry a non-zero content-length. H2Stream._initialize_content_length() only exempts self.request_method == b"HEAD", so the other two statuses are judged by framing alone:

304 + content-length: 1234 + END_STREAM on HEADERS  -> accepted
304 + content-length: 1234 + empty DATA END_STREAM  -> InvalidBodyLengthError

The same applies to 204. This rejects a legitimate response depending only on which frame carried END_STREAM.

What changes

receive_headers() now concretizes the header block once, then _initialize_content_length() treats a response whose :status is 204 or 304 like the HEAD exemption: expected content length is zero, so a bodyless message is accepted and any actual DATA is still rejected. Concretizing the block also avoids re-iterating a generator across informational-status, content-length and header-validation passes.

Tests

New tests/test_bodyless_responses.py:

• 204 and 304 with content-length: 1234 and an empty DATA END_STREAM are accepted;
• the same headers with END_STREAM on HEADERS are accepted;
• a 200 with the same header and empty DATA still raises InvalidBodyLengthError;
• a 304 carrying actual DATA still raises.

On the parent revision the two empty-DATA bodyless cases fail with InvalidBodyLengthError; with the change all 6 pass. Full suite: 1668 passed. ruff check src/ and mypy --strict src/h2/stream.py are clean.