--header "Name: Value" (space after the colon) makes every response fail with the h11 and wsproto protocols

[sungbin1015]

Description

--header splits its argument on the first : and keeps whatever follows verbatim, including leading/trailing whitespace. Writing the header the way it looks on the wire (and the way curl -H takes it), e.g. --header "X-Frame-Options: DENY", stores the value " DENY".

What happens next depends on the protocol implementation:

implementation	result
--http h11	every request fails: h11._util.LocalProtocolError: Illegal header value b' DENY', the connection is closed with no response (curl: (52) Empty reply from server). The access log still prints 200 OK for it.
--ws wsproto	every WebSocket handshake fails with the same LocalProtocolError
--http httptools, --http zttp	works, header is written as x-frame-options: DENY (two spaces)
--ws websockets, --ws websockets-sansio	works

The server starts normally and nothing is reported until the first request, so with plain pip install uvicorn (h11 is what --http auto picks when httptools is not installed) the option turns the whole server into one that answers nothing.

Whitespace around a field value is not part of the value (RFC 9110 section 5.5), so I'd expect the CLI to strip it, and all implementations to send x-frame-options: DENY.

Root cause, on main at 724f82f:

• uvicorn/main.py:494 - headers=[header.split(":", 1) for header in headers] does not strip.
• uvicorn/config.py:496 - the pair is encoded as-is into encoded_headers, which becomes server_state.default_headers (uvicorn/server.py:262).
• uvicorn/protocols/http/h11_impl.py:467,484 - the default headers are passed to h11.Response(...), which validates field values and rejects the leading space. uvicorn/protocols/websockets/wsproto_impl.py:391 hits the same h11 validation through wsproto.

The existing test (tests/test_cli.py::test_cli_headers) only covers Name:Value with no space.

A possible fix is a one-line change at the CLI boundary:

headers=[[part.strip() for part in header.split(":", 1)] for header in headers],

I have this plus a test locally and can open a PR if you agree it's a bug. Note that #2992 (open) touches the same line to reject a missing colon; it does not strip whitespace, so the two don't overlap in behaviour, but the strip could just as well go into that PR's _parse_header().

Programmatic Config(headers=[("X-Frame-Options", " DENY")]) behaves the same way, but there the caller typed the space explicitly, so I'm only reporting the CLI.

Example Code

# app.py
async def app(scope, receive, send):
    assert scope["type"] == "http"
    await send({"type": "http.response.start", "status": 200, "headers": [(b"content-type", b"text/plain")]})
    await send({"type": "http.response.body", "body": b"ok\n"})

$ uvicorn app:app --port 18731 --http h11 --header "X-Frame-Options: DENY" &
$ curl -si http://127.0.0.1:18731/
curl: (52) Empty reply from server

INFO:     127.0.0.1:40262 - "GET / HTTP/1.1" 200 OK
ERROR:    Exception in ASGI application
Traceback (most recent call last):
  ...
  File ".../uvicorn/protocols/http/h11_impl.py", line 484, in send
    response = h11.Response(status_code=status, headers=headers, reason=reason)
  ...
h11._util.LocalProtocolError: Illegal header value b' DENY'

$ uvicorn app:app --port 18731 --http httptools --header "X-Frame-Options: DENY" &
$ curl -si http://127.0.0.1:18731/
HTTP/1.1 200 OK
date: ...
server: uvicorn
x-frame-options:  DENY
content-type: text/plain
transfer-encoding: chunked

ok

Python, Uvicorn & OS Version

Running uvicorn 0.54.0 with CPython 3.11.15 on Linux

main at 724f82f, with the versions pinned in uv.lock: h11 0.16.0, httptools 0.8.0, wsproto 1.3.2, websockets 17.1, zttp 0.0.34, click 8.5.0.

This was found and reproduced with the help of an AI coding assistant (Claude).

[aashish254]

confirmed, it's the split in main.py. line 494 does header.split(":", 1) with no strip, so --header "X-Frame-Options: DENY" keeps the value as " DENY" with the leading space. h11 rejects that as an illegal header value and drops the connection, which is the empty reply you're seeing.

fix is stripping both sides when parsing. httptools and zttp tolerate the space which is why only h11 and wsproto blow up.