-H with no colon sends an empty-valued header instead of being rejected

[korya]

Corrected 2026-08-07. This issue originally claimed the header was silently dropped. That was wrong — it is sent with an empty value. The original finding came from a case-sensitive grep for BareHeader against the canonicalised Bareheader. Verified by an end-to-end test; the corrected behaviour is below.

Problem

A -H value with no colon parses to an empty value and is sent as an empty-valued header, rather than being rejected.

parseHeaderLine("BareHeader") returns name="Bareheader", value="", and req.Header.Add then emits it on the wire.

Reproduction

$ http-assert -H 'BareHeader' --assert-body-eq never-matches http://…/echo
…
GET /echo HTTP/1.1
Host: 127.0.0.1:54859
User-Agent: Go-http-client/1.1
Bareheader:                          ← sent, with an empty value

The echo endpoint confirms the server received it:

{"headers":{"Bareheader":[""], …}}

Why it still matters

The divergence from curl is real, just different from what was first reported:

Input	curl	http-assert
-H 'X-Foo'	removes an internally-generated X-Foo header	sends X-Foo: with an empty value
-H 'X-Foo;'	sends X-Foo: with an empty value	not supported (the ; becomes part of the name)

So a user reaching for curl's remove-a-header idiom gets the opposite of what they asked for, silently. A missing colon is also a common typo, and nothing flags it.

Suggested fix

Reject a -H value with no : as an invalid argument:

Error: Invalid value for --header flag: "BareHeader" has no ':' separator

Note parseHeaderLine is shared with --assert-header*, where a bare name legitimately means "assert present" — so the validation belongs at the -H call site, not inside the parser.

Adopting curl's ; convention would be the fuller fix, but rejecting the ambiguous form is the cheap correct step.

Verified by

TestKnownIssue33BareHeaderSendsEmptyValue pins the current behaviour, so the fix will announce itself by failing that test.