Using Early Data in HTTP
Extracted elements (27)
Because HTTP requests can span multiple hops, two explicit signaling mechanisms are needed: the Early-Data header field (to indicate a request arrived in early data on a prior hop) and the 425 (Too Early) status code (to trigger a retry). Gateways typically lack the information to decide replay safety; only the origin server has that context.
The Early-Data header field carries only a single bit of information (value "1") because what matters is not the details of the early data exchange but simply whether the client understands and is willing to retry on receipt of a 425 (Too Early) response. User agents do not need to set it; their act of sending in early data implies this willingness.
The advice and mechanisms in this document apply equally to the use of 0-RTT in HTTP over QUIC (HTTP/QUIC), not only HTTP over TLS 1.3.
A gateway MUST NOT forward requests received in early data unless it knows the origin server understands the Early-Data header field and will correctly generate a 425 (Too Early) status code. An uncertain gateway SHOULD delay forwarding until the TLS handshake completes or respond with 425 directly.
A server MUST NOT act on early data before the TLS handshake completes if it and any other server instance could make a different decision about how to handle the same data, to prevent inconsistent replay handling across instances.
A server that is under load SHOULD prefer rejecting TLS early data as a whole rather than accepting early data and selectively processing requests, to avoid amplifying load through client retries triggered by 503 or 425 responses.
A user agent that receives a 425 (Too Early) response SHOULD retry automatically, but any retries MUST NOT be sent in early data.
Absent explicit per-resource configuration, origin servers MUST either reject early data entirely or implement the techniques in this document to ensure requests are not processed prior to TLS handshake completion.
An intermediary forwarding a request before TLS handshake completion with its client MUST add the Early-Data header field set to "1" if not already present, and MUST NOT remove the field if it is present.
An intermediary MUST forward a 425 (Too Early) status code if the request it received and forwarded contained an Early-Data header field. Otherwise, an intermediary that received the request in early data MAY retry that request in response to 425, but MUST wait for the TLS handshake to complete first.
An intermediary MUST NOT use early data when forwarding a request unless early data was used on a previous hop, or it has out-of-band knowledge that the request can be retried safely. Absent better information, this means the request must have arrived in early data or with Early-Data: 1.
Clients MAY send requests with safe HTTP methods in early data when available, but MUST NOT send unsafe methods (or methods whose safety is unknown) in early data.
Clients that use early data MUST retry requests upon receipt of a 425 (Too Early) status code.
Early-Data MUST NOT appear in a Connection header field, MUST NOT be included in responses, and MUST NOT appear in request trailers.
If the server rejects early data at the TLS layer, a client MUST start sending again as though the connection were new, which may require a different negotiated application protocol.
Intermediaries that accept early data MUST implement the 425 (Too Early) mechanism so that the origin can signal that a particular request is not appropriate for early data processing.
It is RECOMMENDED that origin servers allow resources to explicitly configure whether early data is appropriate for incoming requests.
Once a server has decided to accept TLS early data, it MUST process all requests received in early data, even if it ultimately rejects individual requests with a 425 (Too Early) response. TLS does not permit selective rejection of early data.
Requests that contain the Early-Data header field and cannot be safely processed MUST be rejected using the 425 (Too Early) status code. A server cannot make such a request safe by waiting for the handshake to complete, because the early data already occurred on a prior hop.
The 425 (Too Early) status code indicates the server is unwilling to risk processing a request that might be replayed. It is not cacheable by default and its payload is not a representation of any identified resource.
The Early-Data request header field signals that the request has been conveyed in early data and that the client understands the 425 (Too Early) status code. It has exactly one valid value: "1". User agents sending early-data requests do not need to include this header; it is intended for intermediaries.
This document registers the 425 (Too Early) status code in the IANA "HTTP Status Codes" registry.
This document registers the Early-Data header field in the IANA "Permanent Message Header Field Names" registry, applicable to HTTP, with status "standard".
Consistent treatment of requests arriving fully or partially in early data is critical: if any server instance might initiate processing before TLS handshake completion, all instances must account for possible replay. Disabling early data, delaying, or rejecting with 425 are equally valid and may be chosen per-instance based on conditions such as server load.
In protocols with out-of-order delivery such as QUIC, early data can arrive after the handshake completes. A server MAY process such requests after handshake completion only if it can rely on other instances correctly handling replays of the same requests.
Using early data exposes a client to the risk that their request is replayed by an attacker. Replayed or retried requests can produce different side effects on the server and may be used for traffic analysis to recover information about requests or target resources, even when content is confidential (via response length differences).
The Early-Data header field has a single ABNF production: `Early-Data = "1"`. Only the value "1" is valid; multiple or invalid instances MUST be treated as equivalent to a single instance with value "1".