Tolerated it and continued. The specification permits this but does not require it; a client that rejected it would also be conformant. The client process had already exited 1052ms in, before this test's reaction point at never observed, so the silence after that is not evidence either way.
The client did what the clause requires.
What was measured
- Client
- picoquic — picoquic + picotls, 8162550
- 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-10-27
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 picoquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["h-extended-connect"]'