Reject empty header names on the outbound path

[avalyset]

Sending a header block with an empty header name raises IndexError instead of ProtocolError.

The inbound pipeline runs _reject_empty_header_names (utilities.py:201) before _reject_pseudo_header_fields (utilities.py:210), so an empty name is caught before this lookup:

# utilities.py:335, in _reject_pseudo_header_fields
for header in headers:
    if header[0][0] == SIGIL:

validate_outbound_headers has no such guard, so header[0][0] indexes into empty bytes:

>>> c = h2.connection.H2Connection()
>>> c.initiate_connection()
>>> c.send_headers(1, [(b":method", b"GET"), (b":path", b"/"),
...                    (b":scheme", b"https"), (b":authority", b"example.com"),
...                    (b"", b"v")])
IndexError: index out of range

Precedent

#1257 reported the same class of failure on the inbound path — IndexError from an empty header name — and the response there was:

Yes - this looks like a valid bug!

#1257

The fix at the time added _reject_empty_header_names, but only to validate_headers. The outbound path was left as it was, so the same IndexError is still reachable, now from _reject_pseudo_header_fields rather than _reject_surrounding_whitespace.

The change

Adds the guard to validate_outbound_headers, in the same position relative to _reject_pseudo_header_fields as inbound.

The message needed to differ by direction — "Received header name with zero length." is wrong for a block we are sending, and an existing test matches on that exact string. Rather than parameterise the generator, I shared the body and kept two thin wrappers, which is the shape this module already uses for direction-specific checks: _check_host_authority_header and _check_sent_host_authority_header both delegate to _validate_host_authority_header and differ only in name and docstring. So _reject_empty_header_names and _reject_sent_empty_header_names now both delegate to _validate_nonempty_header_names(headers, msg).

Tests

Added to tests/test_invalid_headers.py: empty name outbound raises ProtocolError across the validation-flag combinations, the same via send_headers with the message asserted, and a valid name still accepted in both directions.

Against unmodified utilities.py the new tests fail with exactly the reported error:

E           IndexError: index out of range
src/h2/utilities.py:335: IndexError
17 failed, 4 passed

With the fix:

21 passed

Full suite and the lint commands from [tool.tox.env.lint]:

python -m pytest tests            1683 passed
ruff check src/                   All checks passed!
mypy --strict-bytes src/          Success: no issues found in 12 source files

Separate question, not addressed here

While tracing this I noticed the two pipelines have diverged more broadly. Four character classes that inbound rejects are accepted outbound:

	inbound	outbound
CR / LF in value	ProtocolError	sent
NUL in value	ProtocolError	sent
DEL (0x7f) in name	ProtocolError	sent
colon in name	ProtocolError	sent

Verified through send_headers; the bytes reach the wire, e.g. [(b"x", b"a\r\nInjected: evil")]. Uppercase names and surrounding whitespace are handled outbound, but by normalize_outbound_headers rewriting them rather than rejecting.

RFC 9113 § 8.2.1 lists these among the conditions where "A request or response that contains a field that violates any of these conditions MUST be treated as malformed", and config.py:109-114 documents the flag as:

Controls whether the headers emitted by this object are validated against the rules in RFC 7540.

#289 established the principle when it first added outbound validation: "We already have the code to police these rules, so apply it to outbound as well as inbound headers."

I have deliberately left that out of this PR. It is a larger change than a wrong exception type, and it could break callers who send such headers today — that seems like your call rather than something to fold into a bugfix. Happy to open a follow-up if you want it, in whatever shape you prefer.

[Kriechi]

IMO there is no need to separate just on the error message here. Please unify this again and follow similar message styles as already used in the other cases, e.g., "header name with zero length present".

[avalyset]

Merged back into a single generator, used on both paths.

Message is now Header name with zero length present. I dropped the Received prefix rather than keeping your sentence verbatim, because in this file Received ... marks the inbound-only checks, and this one now runs in both directions. The ... present. form follows _reject_connection_header, whose message is Connection-specific header field present: ... — the closest neighbour, being the other both-directions check with a direction-neutral message.

test_inbound_header_name_length_full_frame_decode matched the old string verbatim, so it is updated to the new one in the same commit.