TLS 1.3 can carry application data before a resumed handshake completes, which means an HTTP request can reach server processing earlier than the connection has its final handshake state. That latency optimization changes a security property: early data can be replayed, so a request that is safe to execute once can become unsafe when the same bytes are accepted more than once.
HTTP status 425 Too Early marks the boundary between transport acceptance and application acceptance. A server can accept TLS early data at the connection layer yet decline to process a particular HTTP request from that data. The client can then retry after the handshake completes, where the early-data replay condition no longer applies.
TLS acceptance does not make a request replay-safe
TLS 1.3 early data, often called 0-RTT data, is available on resumed connections. A client that has suitable session state can send application bytes with its first flight rather than waiting for the handshake to finish.
The optimization has a structural limit. Early data lacks the same replay protection as ordinary application data sent after handshake completion. An attacker able to capture an early-data flight can attempt to replay it to another server instance or at another time allowed by the relevant TLS state. TLS deployments can reduce replay exposure, but the protocol does not turn arbitrary early application actions into exactly-once operations.
This distinction matters for HTTP because method semantics and application effects are separate layers. A request can be syntactically valid, authenticated under the eventual connection, and still be unsuitable for execution before handshake completion.
Consider a request that reserves a scarce resource:
POST /reservations HTTP/1.1
Content-Type: application/json
{"slot":"A17"}If application processing creates a reservation, duplicate processing can create duplicate effects unless the application has an independent deduplication mechanism. Sending such a request in early data exposes it to a replay condition that does not exist in the same form after the handshake.
The transport cannot infer the business effect from the request bytes. The application or an HTTP-aware intermediary therefore needs a policy boundary for deciding which requests may proceed.
425 moves the retry past handshake completion
RFC 8470 defines 425 Too Early for a server that is unwilling to risk processing a request that might be replayed. The response does not mean that the request syntax is invalid or that the resource is unavailable. It means the timing and replay properties of the received request are unacceptable.
A simplified exchange has two phases:
resumed connection
client -> request in early data
server -> 425 Too Early
handshake completes
client -> same request in ordinary application data
server -> final application responseThe retry is significant because it changes the transport condition under which processing begins. The server is not asking the client to wait for a resource-specific delay. It is asking for the request to arrive outside early data.
A client that receives 425 should retry automatically, but that automatic behavior is safe only because the retry is sent after the handshake completes. Retrying again in early data would preserve the condition that caused the rejection.
The status code therefore acts as a protocol-level deferral signal. It lets a server preserve the latency benefit for requests that fit its replay policy while refusing early execution for requests that do not.
Safe HTTP methods provide a default boundary, not a universal guarantee
RFC 8470 permits clients to send requests with safe HTTP methods in early data when no other information is available and prohibits sending unsafe methods, or methods with unknown safety, in early data absent stronger knowledge.
HTTP method safety describes intended semantics. GET, HEAD, OPTIONS, and TRACE are defined as safe because the client does not request a state change as the purpose of the method. That makes them better default candidates for replay than methods such as POST.
Safety still depends on correct server behavior. A GET endpoint that performs an externally significant mutation violates the method’s defined safe semantics. Early-data policy cannot repair that mismatch. Replaying such a request can expose the hidden side effect even though the method token is normally classified as safe.
Conversely, an unsafe method can be replay-tolerant when the application has a separate mechanism that makes duplicate submissions harmless under stated conditions. An idempotency key tied to durable deduplication state is one possible mechanism. Its correctness depends on the scope, retention, atomicity, and response semantics of that deduplication design; the method name alone does not establish those properties.
The default method rule is therefore conservative protocol guidance rather than a proof about application behavior.
Intermediaries cannot infer origin replay policy
An intermediary can receive early data and forward a request toward an origin that has no direct evidence about the downstream TLS timing. Without an HTTP signal, the origin might process a request without knowing that its bytes arrived through an early-data path.
RFC 8470 defines the Early-Data request header field for this boundary. An intermediary that forwards a request received in early data can mark that fact so the next server can apply its own replay policy.
The field carries information about request provenance, not permission. Its presence does not assert that processing is safe. It tells a downstream server that early-data considerations apply.
This distinction is important in multi-hop deployments. A TLS terminator, reverse proxy, gateway, and application server can each sit on different connections. The application-facing connection might already have a completed handshake while the original client request entered the system as early data. Propagating the signal preserves the security-relevant fact across that topology.
An intermediary also cannot safely remove the problem by retrying an unsafe request on its own before the origin has had a chance to decide. Automatic replay at the HTTP layer can reproduce the same duplicate-effect risk that the early-data rules are intended to contain.
TLS rejection and HTTP rejection operate at different granularity
A TLS server can reject early data for a resumed connection. That decision applies at the TLS layer and can prevent early application bytes from being accepted as early data.
Once a server accepts early data, however, request-level policy can still vary. One request might be suitable for early processing while another on the same deployment is not. HTTP 425 supplies that finer application-facing decision point.
This separation also matters when a request spans the handshake boundary. A request can begin in early data and finish after handshake completion. The relevant question is not merely where its last byte arrived. If server processing can begin before the handshake completes, replay exposure has to be considered for that processing.
Parsing without acting is different from committing effects. A server can buffer or parse request fields while deferring replay-sensitive work until the handshake state is suitable. The implementation boundary is the point at which externally meaningful processing begins, not merely the point at which bytes become available.
A retry signal does not create idempotence
425 can prevent a server from intentionally processing a replay-sensitive request while it is still exposed as early data, but it does not make the application operation idempotent.
Failures can occur after the handshake as well. A client might send a normal request, lose the response, and face uncertainty about whether the server committed the operation. Retrying in that case is an ordinary distributed-systems ambiguity, independent of TLS early data.
The two mechanisms address different duplicate paths. Early-data handling limits a transport-level replay exposure. Idempotency mechanisms can constrain duplicate application submissions across retries, timeouts, connection failures, or client behavior.
Treating 425 as a general duplicate-request defense leaves those other paths untouched. Treating an idempotency key as a reason to accept all early data can also be too broad if the deduplication store does not cover every server instance or if its retention window is shorter than the relevant replay exposure.
Each control needs a stated scope.
Replay policy belongs at the effect boundary
A useful server policy classifies requests according to the earliest point at which processing can create an effect that must not be repeated. Pure routing, header parsing, authentication preparation, and request-body buffering can often occur without committing application state. Database writes, payment capture, message publication, reservation creation, and other externally visible actions can require stricter treatment.
That classification can be implemented at different layers. A front proxy can reject broad classes such as unsafe methods from early data. An application server can apply narrower rules based on route semantics and deduplication guarantees. Layering both can keep the default conservative while permitting explicit exceptions.
The key constraint is that no layer should claim a stronger replay guarantee than the system actually provides. A proxy that accepts a request because it appears idempotent cannot prove that an origin implementation has no hidden non-idempotent effect. An origin that receives an Early-Data signal has the final application context needed to make that decision.
Observability should preserve the same boundary. Logs that record whether a request arrived through early data, whether it was rejected with 425, and whether a later retry was processed can distinguish transport deferral from application failure without implying that duplicate execution was impossible.
Early data trades handshake delay for a narrower execution envelope
TLS early data removes a wait from resumed connections by allowing application bytes to move before handshake completion. The cost is a weaker replay property for those bytes. HTTP does not erase that trade; it exposes controls that let request processing respect it.
Early-Data carries the relevant provenance across HTTP hops. 425 Too Early lets a server decline processing until the request is outside the early-data condition. Safe method semantics provide a conservative client default, while application-specific deduplication can support narrower exceptions when its guarantees are explicit.
The resulting boundary is precise: accepting early bytes is not equivalent to accepting their effects. Systems that keep those decisions separate can use 0-RTT where replay is tolerable and defer replay-sensitive work without treating the entire connection as unusable.