Skip to content

425 Too Early

The server refuses to process a request sent in TLS 1.3 early data because it might be a replay.

Status

HTTP/1.1 425 Too Early

Details

  • Category: 4xx
  • Status: Standard. Registered with IANA and defined by a current standards-track RFC.
  • Specification: RFC 8470 §5.2
  • Cacheable: Not cacheable
  • Response body: Allowed
  • Retry: Safe to retry

TLS 1.3 lets a client send data in the first flight when resuming a session, saving a round trip. Early data has a weakness: a network attacker can capture and replay it. A server that will not risk replaying a state-changing request answers 425 and asks the client to send it again after the handshake completes.

The right policy is to allow early data for safe, idempotent requests and to reject it for anything that changes state.

Headers

  • Early-Data: Set to 1 by an intermediary to tell the origin the request arrived in early data.

Common causes

  • A 0-RTT request carried a non-idempotent method the server declines to accept early.
  • A CDN or reverse proxy forwarded early data to an origin configured to reject it.

How to fix it

As the client

  • Retry the request over the completed handshake rather than in early data.
  • Restrict 0-RTT to GET and HEAD in the client, and never use it for writes.

As the server

  • Reject early data for unsafe methods and accept it for safe ones.
  • Forward the Early-Data header so origins can make the decision themselves.

Examples

A state-changing request sent as early data

HTTP request

POST /api/payments HTTP/1.1
Host: api.example.com
Early-Data: 1

HTTP response

HTTP/1.1 425 Too Early

Browser compatibility

  • Chrome: not supported
  • Edge: not supported
  • Firefox: since 58
  • Opera: not supported
  • Safari: not supported

Specifications

See also