Tolerated it and continued. The specification permits this but does not require it; a client that rejected it would also be conformant.
The client did what the clause requires.
What was measured
- Client
- curl — ngtcp2 + nghttp3, ngtcp2/1.11.0
- Test
- SETTINGS_ENABLE_CONNECT_PROTOCOL with a value outside 0 and 1 —
h-extended-connect - Clause
- RFC 9220 §3, RFC 8441 §3 (MUST)
- Class
- discretionary — The RFC permits either behaviour; the report says which was chosen.
- Required behaviour
- Reject it or ignore it, but keep working. RFC 8441 §3 says the value "MUST be 0 or 1" and RFC 9220 carries that into HTTP/3 unchanged — yet neither names a behaviour for a receiver that sees anything else, so both answers are conformant and stalling is not. The setting is how a client learns Extended CONNECT is available, so a WebTransport-capable client has real parsing behind it.
- Measured
- 2026-09-18
Reproduce it
The suite is the judge, so the reproduction is to point the same client at the same test and let the server report what it saw.
SESSION=$(curl -sX POST https://conformance.pqcrypta.com/session | jq -r .id)
# then drive curl at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["h-extended-connect"]'