lsquic — SETTINGS_ENABLE_CONNECT_PROTOCOL with a value outside 0 and 1

Pass

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

lsquic — LiteSpeed lsquic + BoringSSL, 4.9.4

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 lsquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["h-extended-connect"]'