grants this endpoint 3 unidirectional streams -- the control stream and the two QPACK streams HTTP/3 requires take them all -- and granted no more within 500ms, so a push stream could not be opened. The violation cannot be delivered to this client; its stream limit rules it out.
The client does not do this, and said so itself — by what it advertised, or by refusing outright. A definite answer about the client, not a failure and not a gap.
What was measured
- Client
- lsquic — LiteSpeed lsquic + BoringSSL, 4.9.4 (2b30189)
- Test
- Push stream opened for a push nobody allowed —
h-push-stream-unpromised - Clause
- RFC 9114 §6.2.2 (MUST)
- Class
- correctness — Rejected something invalid, with the code the RFC names.
- Required behaviour
- Close the connection with H3_ID_ERROR. §6.2.2 does not require the push to have been promised first — the stream alone is enough: a client "MUST treat receipt of a push stream as a connection error of type H3_ID_ERROR when no MAX_PUSH_ID frame has been sent", and no client under test sends one. Distinct from the PUSH_PROMISE test, which puts the same violation in a frame on the control stream. This one opens the push stream itself, which a client has to recognise by its stream type before any frame inside it is read.
- 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 lsquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["h-push-stream-unpromised"]'