msquic — 425 (Too Early) in answer to a request sent as early data

Fail

Closed without an error code. Rejecting this is permitted, but doing so silently leaves the peer unable to tell what happened.

The client did something the clause forbids, or failed to do what it requires.

What was measured

Client

msquic — .NET HttpClient + msquic, 2.7.0

Test

425 (Too Early) in answer to a request sent as early data — q-zero-rtt-replay

Clause

RFC 8470 §5.2 (SHOULD)

Class

discretionary — The RFC permits either behaviour; the report says which was chosen.

Required behaviour

Handle being told the request arrived too early. §5.2 says a user agent "SHOULD retry automatically, but any retries MUST NOT be sent in early data" — so retrying on the 1-RTT keys and handing the 425 back to the caller are both conformant, and the report says which happened. Falling over is not one of the options. This is the only port that *accepts* early data instead of refusing it, which is what makes the 425 exchange possible at all. What it does not check is §4's rule that unsafe methods must never be sent in early data: reading the method would mean QPACK-decoding the request, which this suite deliberately never does. Reaching it needs a session ticket from an earlier connection to this same port, so a client that connects once has none.

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 msquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-zero-rtt-replay"]'