425 Too Early
The server refuses to process a request sent in TLS 1.3 early data because it might be a replay.
Status
HTTP/1.1 425 Too Early
Details
- Category: 4xx
- Status: Standard. Registered with IANA and defined by a current standards-track RFC.
- Specification: RFC 8470 §5.2
- Cacheable: Not cacheable
- Response body: Allowed
- Retry: Safe to retry
TLS 1.3 lets a client send data in the first flight when resuming a session, saving a round trip. Early data has a weakness: a network attacker can capture and replay it. A server that will not risk replaying a state-changing request answers 425 and asks the client to send it again after the handshake completes.
The right policy is to allow early data for safe, idempotent requests and to reject it for anything that changes state.
Headers
- Early-Data: Set to 1 by an intermediary to tell the origin the request arrived in early data.
Common causes
- A 0-RTT request carried a non-idempotent method the server declines to accept early.
- A CDN or reverse proxy forwarded early data to an origin configured to reject it.
How to fix it
As the client
- Retry the request over the completed handshake rather than in early data.
- Restrict 0-RTT to GET and HEAD in the client, and never use it for writes.
As the server
- Reject early data for unsafe methods and accept it for safe ones.
- Forward the Early-Data header so origins can make the decision themselves.
Examples
POST /api/payments HTTP/1.1 Host: api.example.com Early-Data: 1 HTTP/1.1 425 Too Early