425 Too Early

The server is unwilling to process a request that might be a replay, typically one sent as TLS 1.3 early data.

Defined in RFC 8470 §5.2

What 425 means

RFC 8470 defines 425 for TLS 1.3's 0-RTT "early data" feature. A returning TLS 1.3 client can send application data, including a full HTTP request, in its very first network flight, before the handshake has fully completed, cutting a round trip off connection setup. RFC 8470 lets a server reject such a request with 425 when it is not safe to process before the handshake is confirmed.

The risk is replay: an attacker who captures the encrypted early-data packets can resend them, and because the handshake is not yet confirmed at that point, the server cannot yet distinguish a replay from the original request. RFC 8470 recommends rejecting early-data requests for anything non-idempotent, such as POST, PUT, or DELETE, unless the application is specifically known to be safe under replay, while allowing safe methods like GET through.

CDNs including Cloudflare were early adopters of 0-RTT and popularized 425 in the wild. A server or proxy forwarding early data is expected to set the Early-Data: 1 header so downstream systems know the request has not yet cleared a confirmed handshake; a client that receives 425 is expected to simply retry the identical request once the connection is fully established.

Common causes

A client sends a non-idempotent request, such as POST, PUT, or DELETE, as TLS 1.3 0-RTT early data.
Server or CDN policy rejects early data for any endpoint that is not provably safe under replay.
Middleware detects that the request arrived before the TLS handshake was fully confirmed and marks it as early data.
A load balancer forwards the Early-Data header and the origin enforces a reject policy on flagged requests.

How to fix a 425

If you are the client (browser user or API caller)

Retry the exact same request once the TLS handshake has fully completed, not as early data.
Avoid sending non-idempotent requests as 0-RTT early data in the TLS client configuration.
Expect and handle 425 as a normal, retryable outcome when 0-RTT is enabled.

If you run the server

Reject only non-idempotent or otherwise replay-sensitive requests as early data, while allowing safe methods like GET through.
Set the Early-Data header correctly when forwarding through proxies or CDNs so the origin can make an informed decision.
Document which endpoints are considered replay-safe so 0-RTT can be used more aggressively where it is actually safe.

Example

POST /checkout HTTP/1.1
Host: shop.example.com
Early-Data: 1
Content-Type: application/json

{"orderId": "abc123"}

HTTP/1.1 425 Too Early
Content-Type: application/json

{"error": "retry after the TLS handshake completes"}

A non-idempotent POST arrived as 0-RTT early data and is rejected until the handshake is confirmed.

Try it live

Our free status responder returns a real HTTP 425 you can point tests, monitors or a browser at.

GET https://mcp.httpstatus.com/status/425