The client completed its request and closed without objecting, but the anomaly was written to the control stream — a unidirectional stream nothing obliges it to read on any schedule. A one-shot request can finish before that stream is picked up, so this is equally consistent with accepting the violation and with never having seen it, and neither can be told from here.
The run did not establish what this client does here — either it was never put in the situation, or its answer admits more than one reading. Not a failure, and never counted as one.
What was measured
- Client
- picoquic — picoquic + picotls, 8162550
- Test
- CANCEL_PUSH for a push ID that was never promised —
h-cancel-push-unsolicited - Clause
- RFC 9114 §7.2.3 (MUST)
- Class
- correctness — Rejected something invalid, with the code the RFC names.
- Required behaviour
- Close the connection with H3_ID_ERROR. No MAX_PUSH_ID was granted, so every push ID is greater than currently allowed, and §7.2.3 requires a CANCEL_PUSH referencing one to be treated as a connection error of that type.
- 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 picoquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["h-cancel-push-unsolicited"]'
What this suite is · The full grid · All clients · All tests · Findings