does not resume sessions, so nothing was rejected. An earlier connection to this port in the same session completed its exchange, and with it received session tickets that permit 0-RTT; this connection, opened afterwards, ran a full handshake instead of resuming, and a client that does not resume cannot offer early data.
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
- msquic — .NET HttpClient + msquic, 2.7.0 (7e6525d)
- Test
- 0-RTT rejected after the client sends early data —
q-zero-rtt-reject - Clause
- RFC 9001 §4.6.2 (MUST)
- Class
- resilience — Recovered rather than giving up.
- Required behaviour
- Reset the state of every stream, including application state bound to them. Section 4.6.2 requires the reset because a rejected 0-RTT means every assumed connection characteristic may have been wrong. It does not require retransmission, which is the application concern, not QUIC's. This port issues tickets that advertise early data and then declines every offer, so a resuming client sends 0-RTT and always has it refused. The handshake itself completes normally.
- 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 msquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-zero-rtt-reject"]'