Review HTTP 425 Before Early Data Replays a Product Action

Begin with the action that must not repeat

TLS early data can reduce a connection round trip, but the server may receive the same early bytes more than once. Start with a product action where that matters. In the working fixture, a client asks to hold one synthetic reservation. The request passes through a gateway to an origin that records the hold. If a replay creates two holds or extends the expiry twice, the optimization has changed product behavior. Write the expected database state before configuring the gateway, and give the reservation owner authority over whether any replay risk is acceptable.

Do not classify safety from GET, POST, or another method name alone. A nominally safe request can trigger expensive generation, consume a one-time token, or call a dependency with side effects. A POST may already have an idempotency boundary that makes a duplicate observable and harmless. Trace authentication, authorization, cache lookup, database work, queue publication, remote calls, and response generation for the selected route. The result is a route-level replay decision, not a blanket rule that every read is safe and every write must be slow.

Map every TLS and HTTP hop

Draw the client, edge, content delivery network, load balancer, service mesh, and origin connections separately. Mark where TLS terminates and where a new TLS connection begins. The origin might never see transport-level early-data state from the public client because a gateway accepted and forwarded the request over another connection. RFC 8470 defines the Early-Data request header so that an intermediary can carry this risk signal forward. The header has the value 1, and a forwarding intermediary must not erase it merely because its own handshake has finished.

Document which component enables early data, which adds the signal, which components preserve it, and which component makes the route decision. Treat a client-supplied Early-Data header as untrusted at the public boundary. The owned gateway should normalize forwarding metadata under the same trust model used for host and client address information. Capture configuration revisions without dumping session tickets or traffic secrets. If the team cannot show how the signal reaches the origin, the origin cannot make the route-specific decision promised by the design.

Separate defer, reject, and process decisions

A server has more than one response to early data. It can refuse early data at the TLS layer, defer HTTP processing until the handshake completes, process a route whose replay consequences are acceptable, or return 425 Too Early so a capable client retries without early data. Record which option applies at each hop. Waiting on the origin connection cannot remove replay risk already introduced on a previous hop, which is why a forwarded Early-Data signal still matters after the gateway-to-origin handshake completes.

Use 425 for the condition it describes. RFC 8470 says a server should not emit it unless the request was received in early data or carries Early-Data: 1. It is not a substitute for a load-shedding response, a generic retry signal, or an application conflict. A client that used early data is expected to retry after receiving 425, and that retry must not use early data. Preserve the response through intermediaries and confirm that an ordinary request does not enter an automatic retry loop because a component uses 425 for unrelated failures.

Run a replay-shaped fixture through the real gateway

Build a disposable route around reservation R-17 and a synthetic account. Send the request normally, as declared early data, and as the same early-data request delivered twice. The unsafe route should return 425 or remain deferred before it changes state. The subsequent non-early retry may create exactly one hold. Observe gateway decision, forwarded header class, origin decision, response status, reservation version, audit event, and downstream messages. Keep raw session material out of the record. The database assertion matters more than a screenshot of the response.

Add a route that is deliberately replay tolerant, such as a versioned static lookup with no hidden side effect, and show the contrast. Then try missing, repeated, and malformed Early-Data header fields, different gateway instances, an origin replica change, a delayed first request, a retry after 425, and a client that cannot retry automatically. The standard treats invalid or multiple header instances conservatively. The test should also prove that the gateway does not remove an existing signal and that every origin replica reaches the same safety decision for the same route revision.

Keep idempotency and early-data policy distinct

An idempotency key can reduce the consequence of a duplicate, but it does not make an unexplained early-data path acceptable by itself. Define the operation identity, tenant scope, request fingerprint, retention period, concurrent acquisition rule, stored outcome, and behavior after partial failure. A key reused with different reservation details must fail rather than return an unrelated success. Two replicas racing on the same key need one atomic owner. If the retention window is shorter than the plausible replay window, the database may accept a replay after its evidence has expired.

Test the early-data rule without idempotency, then test idempotency without the signal, and finally combine them. This exposes which control stops which failure. If the early request receives 425, it must not reserve an idempotency record that blocks the later safe retry. If processing begins and fails after an external side effect, the recovery contract must not pretend that a transport retry can repair uncertainty. Product owners decide duplicate meaning, security owners decide replay exposure, and developers implement the reviewed boundaries with observable results.

Hand off a route table and rollback trigger

The handoff should contain a route table with replay consequence, chosen early-data action, idempotency dependency, client retry expectation, gateway rule, origin rule, and decision owner. Include TLS endpoints, trusted forwarding boundary, configuration hashes, fixture identities, state assertions, metrics, unsupported clients, rollout order, and a rollback trigger. Count 425 responses by route and client class, but avoid treating a low count as proof that replay cannot happen. A missing signal or inconsistent origin decision is a stop condition, not a reason to broaden the safe list.

An offshore API developer can prepare the topology, configuration change, synthetic harness, state assertions, dashboards, and rollback patch in an approved environment. The client security and platform owners control TLS policy and trusted intermediaries. Product and service owners approve the replay consequence for each action, while the release owner controls production enablement. Bring one route, its gateway chain, and its duplicate-effect rule to a Developer Offshore contact discussion. That is enough to scope useful work without turning a latency experiment into authority to change transaction semantics.

Questions about assessing Philippine developers