HTTP 425 Too Early – Free, Online, Private

What HTTP 425 means

425 tells a client that the server is unwilling to process a request that might be replayed, which is the early-data case in TLS. The client should retry after the handshake is complete and not send that request as early data again. It is defined in RFC 8470. It is not a rate limit. A client that does not use early data should not see it.

425 Too Early belongs to the 4xx client error class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 425

When you see HTTP 425 Too Early, stop on that exact status line. 425 Too Early means the server refused a request that might be replayed before the handshake finishes. The trace that usually produces it: A POST was sent as TLS 0-RTT early data and the server refused the risk of a replay. The 4xx client error class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 425 if you reject TLS early data for a request that is not safe to replay. Safe methods may still be processed early. Anything with a side effect should wait. Do not use 425 as a general 'slow down'. That is 429. Do not use it for a clock-skew error.

How to fix HTTP 425

To fix HTTP 425, change the condition that made the server choose Too Early. Retry once, not as early data. Do not treat it as a permanent failure. Do not loop: one retry after the handshake is the whole recovery. Yes, once, after the handshake. No further retry is implied if that attempt fails with a different status. If the log line is a different code, leave this page. The mix-up people make with 425 is this one: 429 means you sent too much. 408 means the server waited for the client. 425 means the server will not risk a replay of early data.

• A client retried the POST as early data again and received 425 again.
• A server returned 425 for ordinary traffic and clients backed off as if they were failing.
• A proxy stripped the early-data signal and the origin could not decide, so it rejected more than it needed to.

An access log that only stores 425 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 425 Too EarlyHTTP/1.1 425 Too Early

The client retries the same request on the now-complete connection and should not mark it as early data. There is no Retry-After. The delay is 'when the handshake finishes', which is immediate from the application's point of view. If you see 425 on a request you did not send early, something in the stack is mislabeling traffic.

What the client should do

Retry once, not as early data. Do not treat it as a permanent failure. Do not loop: one retry after the handshake is the whole recovery.

Do not cache 425. The same request may succeed a moment later.

Yes, once, after the handshake. No further retry is implied if that attempt fails with a different status.

Codes people confuse with HTTP 425

429 means you sent too much. 408 means the server waited for the client. 425 means the server will not risk a replay of early data.