v154 · webtransport headers
What the handshake carries
A WebTransport session begins with an HTTP/3 CONNECT. Write the headers you want it to carry and watch each one be accepted, silently dropped, or rejected outright — decided by building a real Request and reading back what survived, not by consulting a list.
Compose the CONNECT
The request that produces
| header | outcome | why |
|---|
Each line is put into new Request(url, { headers }) and read back. A Request carries the request guard, which is where the forbidden-name rules actually live — a bare Headers object has no guard at all and will happily hold a Cookie you can never send. That difference is why this page builds a request rather than a header list.
And what comes back
HTTP/3 200
sec-webtransport-http3-draft: draft02
x-session-id: 4f2a91
x-protocol-version: 3
transport.responseHeaders exposes that reply, so the server can answer with what it negotiated — a session id to correlate with its own logs, the protocol version it settled on, a rate limit. Before this, none of that could arrive until the first datagram, which meant the client had to open a session before it knew whether the server agreed with it.