HTTP 425 Too Early
HTTP 425 Too Early is returned by servers that refuse to process a request sent in TLS 1.3 early data — also called 0-RTT (zero round-trip time) data — because the request could potentially be replayed by an attacker. It is defined in RFC 8470 and is specific to the TLS 1.3 handshake optimization.
Quick reference
| Code | 425 |
|---|---|
| Name | Too Early |
| Category | 4xx Client Errors |
| Specification | RFC 8470 |
| IANA status | Assigned |
| Client behavior | Wait for the TLS 1.3 handshake to complete (1-RTT), then retry the request. Do not retry in early data. |
| In-depth guide | HTTP 425 TLS early data guide → |
What it means
TLS 1.3 introduced 0-RTT session resumption, which allows a client that has previously connected to a server to send data immediately with the first TLS packet — before the handshake is complete. This reduces latency significantly for repeat visitors because the client does not need to wait for a round-trip before sending the HTTP request.
The security tradeoff is replay vulnerability: a network attacker who captures a 0-RTT packet can replay it against the server, potentially causing the same request to execute twice. For idempotent requests (GET, HEAD) this is usually acceptable. For non-idempotent requests (POST, PUT, DELETE) a replay could cause duplicate transactions — submitting a payment twice, creating a duplicate record, or sending a message twice.
RFC 8470 gives servers a mechanism to reject early-data requests they consider replay-unsafe: return 425. The client is expected to wait for the full TLS handshake to complete (1-RTT) and then retry normally. The 425 is not a permanent failure — it is a "not yet, wait for the secure channel" signal.
The Early-Data header
RFC 8470 defines an Early-Data: 1 request header that clients or TLS termination proxies can add to requests forwarded from 0-RTT TLS connections. This lets the origin server identify early-data requests even when TLS termination happens at a separate layer (e.g., at a CDN). Servers that want to protect against replays can check for this header and return 425 for non-idempotent methods.
When servers return 425
A server should return 425 for non-idempotent requests (POST, PUT, PATCH, DELETE) received in 0-RTT early data, where a replay would cause a harmful side effect. Idempotent requests in early data are generally safe to process — replaying a GET returns the same resource twice, which is harmless.
Not all servers implement 425. Many servers simply accept all early-data requests, accepting the theoretical replay risk in exchange for the latency benefit. The use of 425 is most critical for payment endpoints, authentication endpoints, and any operation where duplicate execution has real consequences.
Client handling
When a client receives 425, the correct response is to wait for the TLS 1.3 handshake to complete fully and then retry the exact same request over the fully established connection. The request is not fundamentally broken — it just cannot be sent as early data. Browsers handle this transparently; API clients should implement 425 as a "retry without early data" signal rather than surfacing it as a user-visible error.
425 vs 429 vs 503
| Code | Meaning | Retry? |
|---|---|---|
| 425 | Request arrived in TLS early data — wait for full handshake | Yes — after handshake completes |
| 429 | Rate limit exceeded — too many requests from this client | Yes — after Retry-After delay |
| 503 | Server unavailable — overloaded or in maintenance | Yes — after Retry-After delay |
See also: 425 vs 429 comparison
Related resources
On this site: HTTP 425 TLS early data guide · HTTP 429 Too Many Requests · HTTP 426 Upgrade Required · All 4xx client errors
Comparisons: 425 vs 429
Standards: RFC 8470 · IANA Registry · MDN Web Docs: 425