HTTP 425 Too Early explained

The 425 Too Early status is one of the least common HTTP responses a server can send, and almost all site owners will never see it. When it does appear it is usually a sign that TLS early data, also called 0-RTT, is in use and the server decided it was not safe to process the request yet.

What it means

425 Too Early, defined in RFC 8470, tells a client that the server is unwilling to risk processing a request because it arrived in TLS 1.3 early data and may therefore be a replay. It is a 4xx client error, but the client is not at fault: the server is asking it to wait for the TLS handshake to fully complete and then retry the request normally.

Two details from the RFC matter for understanding it:

• A retry after a 425 must not itself be sent in early data.
• The status is not cacheable by default, because its payload is not the representation of any resource.

A server should only emit 425 for a request that actually travelled in early data, or that carried an Early-Data: 1 header. It should not be sent for ordinary requests.

When it appears

TLS 1.3 gives a client that spoke to a server recently the option to send application data, including the first HTTP request, in the very first round trip, before the handshake finishes. This is 0-RTT early data, and it trades a faster response for a replay risk: an attacker who captured that first flight could replay it to the server, which is damaging for state-changing requests such as a payment or a login.

The server cannot reject early data selectively at the TLS layer. TLS only lets it accept all early data or none, so once it accepts early data on a connection it must process the requests in it, even if that processing ends in a 425. When HTTP does not allow a direct replay of the request, typically for non-safe, non-idempotent methods, the server replies 425 instead of acting on a possibly duplicated action.

The practical effect is that 425 belongs to TLS 1.3 on the query path. It is rarely the direct symptom a developer sees; it usually sits behind a retry that succeeded immediately, which is why it stays unseen.

How to handle it

For most people, no action is needed. Browsers and libraries that support early data are expected to retry the request after the handshake completes, and the page simply loads a moment later.

If you are building or operating a service and deliberately want to avoid ever processing early data for sensitive endpoints, the reliable options are:

• Reject early data for the connection, if the server permits it, so no request is ever admitted as early data in the first place.
• Require your application to treat retries and repeated submissions as safe by making the endpoint idempotent, so even a genuine replay causes no harm.
• For the specific replay-prone actions, need the retried request to be idempotent anyway, since the protocol cannot guarantee only one copy is ever processed.

If you enable early data for performance, do it only for safe, idempotent, read-only requests, where a replayed copy is harmless. That is exactly the split RFC 8470 encourages. See tls 1.3 handshake and HTTP/3 and QUIC for the surrounding transport context.