HTTP 425 Too Early
HTTP 425 Too Early comes from RFC 8470, which governs using early data in HTTP. TLS 1.3 0-RTT early data lets a client send request data before the handshake completes, but such data can be replayed by an attacker. A server returns 425 to indicate it is unwilling to process a request that arrived in early data and asks the client to retry once the handshake is complete.
What this means
TLS 1.3 introduced 0-RTT (zero round-trip time) early data, which lets a client send application data in its first flight to reduce latency on resumed connections. The trade-off is that early data is not protected against replay: an attacker who captures it could resend it.
RFC 8470 defines 425 Too Early so a server can refuse to process a request conveyed in early data when replaying it would be harmful — for instance a non-idempotent write. The client is expected to retry the request after the TLS handshake fully completes, when replay protection is in place.
Common causes and fixes
425s appear at edges and CDNs that accept TLS 1.3 early data and apply replay protection to sensitive requests. Idempotent GETs are often allowed in early data, while writes may be deferred or rejected with 425.
If 425s are disrupting clients, options include disabling 0-RTT for affected routes, restricting early data to safe idempotent methods, or ensuring clients correctly retry on 425 after the handshake. Most search and AI crawlers issue idempotent GETs, so a 425 is more commonly tied to API or write traffic than to ordinary content crawling.
- Triggered by requests sent in TLS 1.3 0-RTT early data
- Server refuses to risk processing replayable early data
- Client should retry after the full handshake completes
How it appears in analytics and logs
A 425 means a request arrived in TLS 1.3 0-RTT early data and the server declined to process it for replay-safety. It is a protocol-safety signal, not a content error; the client should retry after the full handshake.
Diagnostic use case
Diagnose failures where a client sends a non-idempotent request in TLS 1.3 early data and the server refuses it with 425 to avoid replay risk.
What WebmasterID can help detect
WebmasterID records the status returned to crawler fetches, so 425s flag early-data handling at your edge rather than a content problem, separate from human analytics.
Common mistakes
- Allowing non-idempotent writes in TLS 1.3 early data without replay safeguards.
- Treating 425 as a content error instead of an early-data safety signal.
- Failing to retry on 425 after the handshake completes.
Privacy and accuracy notes
A 425 is a TLS-layer safety response with no visitor identity attached. WebmasterID records crawler fetch statuses without linking them to a person.
Related pages
- HTTP 421 Misdirected Request
HTTP 421 Misdirected Request (RFC 9110) is returned when a server receives a request directed at an authority (host) it cannot or is unwilling to produce a response for over the current connection. It frequently arises with HTTP/2 connection coalescing, where a client reuses one TLS connection for multiple hostnames that share a certificate but are not all served by that backend.
- HTTP 426 Upgrade Required
HTTP 426 Upgrade Required (RFC 9110) is returned when a server refuses to process a request on the current protocol and requires the client to upgrade. The response must include an Upgrade header naming the required protocol and a Connection: Upgrade header. A common use is insisting clients move to a newer protocol or to TLS before the request can proceed.
- How CDNs interact with crawlers
A CDN sits between crawlers and your origin, so it shapes what crawlers see: cached responses, edge-served status codes, bot-management challenges, and region-specific edges. Configured well, a CDN speeds crawling and absorbs load; configured poorly, it can block legitimate crawlers, serve stale or wrong content, or return CDN-specific errors that look like origin problems. Understanding the interaction prevents silent crawl failures.
- Website observability
See TLS early-data status codes like 425 at your edge, recorded server-side.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.