Retry a 425 outside early data
03A 425 response refuses the replay risk; a user agent that used early data retries after the handshake, outside early data.
The handshake has completed. The retry is normal application data, with its eventual response left unspecified.
Source for this drawing: RFC 8470 · Read RFC section 5.2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- 425 Too Early
- A refusal to risk processing a possibly replayed HTTP request, not a general rate-limit response.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A retry triggered by 425 MUST NOT use early data.
- 425 Too Early indicates unwillingness to risk processing a request that might be replayed. Clients that use early data MUST retry on receiving 425; automatic retry is SHOULD, not a separate MUST.
- Any user-agent retry after 425 MUST NOT be sent in early data. If the TLS handshake is still incomplete, the retry waits until it completes.
- A server SHOULD NOT emit 425 unless the request arrived in early data or Early-Data is set to 1, because it otherwise cannot assume retry support. A 425 is not cacheable by default; its payload is not a representation of an identified resource.
Fictional direct connection: an early GET is refused with 425; the client waits for handshake completion, then retries as normal application data. This does not guarantee a later 200 or prove no replay happened elsewhere. TLS-layer rejection is a different event, with new-connection-state sending rules in §4.
Read the RFC section ↗