The direct answer
Decide whether the exact route can tolerate replay before dispatching work from TLS early data. Bind the request to a timely trusted observation and a consistent handling policy; a later empty early-data variable is not proof that the request was never early. Keep model spending, current rights and effect uniqueness as independent gates.
Ask what could happen if this request is repeated
A fictional AI service exposes a public catalogue P-A and a protected summary route M-A. P-A returns fixed admitted public text. M-A starts chargeable model work. Both may appear to be reads, but repeating their complete operations has different consequences. The route owner must identify those consequences rather than classify safety from a method or friendly route name.
RFC 8470 distinguishes attacker replays of TLS early data from ordinary retries. It makes tolerance resource-specific, warns that nominally safe methods can have side effects, and requires consistent handling across server instances.
This original worksheet selects one NGINX HTTP ingress I-A that directly terminates the client’s TLS connection. Other terminators, CDNs, HTTP/3 and re-encryption hops are excluded. No production topology, server build or client was inspected. All eight cards are PROPOSED_UNRUN; no TLS, HTTP, configuration or model experiment occurred.
Record what the selected variable can actually say
The NGINX SSL module reference documents ssl_early_data as off by default, introduced in 1.15.3, with OpenSSL 1.1.1-or-later support documented from 1.15.4. The module requires explicit build support. This unversioned reference establishes neither an installed build nor a recommendation to enable early data.
Crucially, $ssl_early_data returns 1 when TLS 1.3 early data is used and the handshake is incomplete; otherwise it is empty. A later empty value cannot distinguish a never-early request from an earlier condition that is no longer represented.
For I-A, require independently supported evidence of where the request is first acted upon, when its observation was obtained, and how that disposition remains associated with this request. A log sampled later cannot repair missing evidence. No NGINX phase hook, capture mechanism, enforcement directive or timing guarantee is implemented here. Unknown timing holds protected dispatch.
Do not erase the protocol’s earlier-hop signal
RFC 8470 section 5.1 assigns Early-Data the value 1; invalid or multiple instances receive the same conservative treatment. Waiting for a local handshake cannot clear an earlier-hop mark. Section 5.2 limits when 425 is appropriate and requires retries not to use early data.
Our direct-termination profile does not treat an incoming field as a trusted replacement for local TLS evidence, nor discard it because it could have been caller-supplied. An unexpected earlier-hop indication means the declared topology or request classification is insufficient. The application must retain the conservative protocol disposition rather than mark protected work ordinary from a later empty variable.
The proposed record therefore separates observed-early, protocol-marked, supported-post-handshake handling and unknown. The last category is not shorthand for ordinary traffic. Actual field processing, request association and topology enforcement require a separately supported complete implementation; this worksheet provides no header parser or forwarding configuration.
Make the first-action boundary part of the route plan
Invent a protected review sheet binding I-A’s build and topology revision, request association, observation timing, route revision and permitted next stage. Before deployment, the team must establish that the gate precedes upstream model dispatch and every state-changing action on all relevant instances. An intended ordering in a diagram is not evidence that callbacks, alternate routes or another instance obey it.
For M-A, observed early or protocol-marked traffic is withheld under the selected policy. A supported ordinary path may remain useful after handshake-complete handling, consistent instance policy and current authorization are established. The positive does not require labelling the request never-early; it requires supported admission at the actual acting boundary.
P-A is a separate conditional positive: its entire operation, including accounting, authorization, hooks and logging consequences, must have an independently reviewed replay-tolerance decision. Fixed response text alone is insufficient. Neither positive is available in a real deployment until the unimplemented build, timing, topology and route prerequisites are established.
Walk eight inert route-admission cards
| Invented condition | Proposed disposition |
|---|---|
| Supported post-handshake acting boundary, consistent instances, current rights and ordinary M-A gates hold | Admit only the authorized normal dispatch plan. Claim no model call or completed result. |
| Timely early-data evidence reaches M-A, which would consume model usage | Withhold upstream work; authentication does not remove this transport-phase decision. |
| Early or protocol-marked traffic requests a metadata change or external message | Withhold the effect under this profile. Do not infer repeat tolerance from a method name. |
| P-A has a complete, separately supported whole-operation replay-tolerance review | Conditionally admit only that bounded public response route, not all catalogue siblings or reads. |
| Only a later empty variable or unexplained field is available | Hold protected admission; absence of timely evidence is not never-early proof. |
| A CDN, another TLS terminator or inconsistent instance appears | Outside the admitted topology or policy. Do not transfer I-A’s local observation across it. |
| A 425 response was sent but earlier upstream activity is possible | Preserve uncertain work and usage; the response cannot retroactively establish prevention. |
| The client retries or the operation is otherwise repeated | Apply independent current-rights, budget and effect-state controls. No exactly-once claim follows. |
Record minimized case, route-policy, evidence-category and dispatch dispositions rather than request bodies, TLS secrets or complete headers. These are invented decisions, not generated requests or measured replays.
Use rejection without promising a retry controller
RFC 8470 defines 425 for unwillingness to risk processing replayable traffic; it is not a generic busy response. A server should not emit it without early receipt or the relevant field. It is not cacheable by default.
Our worksheet implements neither that response path nor client retry behavior. It supplies no automatic resend, replay store, clock policy, cryptographic protection or rollback. The budget guide still governs uncertain usage, and the effect-state guide covers a different duplication boundary.
No latency, resource ceiling or complete coverage result was measured. Boundary is prelaunch and does not ship this TLS ingress or anti-replay controller. Its synthetic policy evidence concerns different behavior.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.