HTTP 425 Too Early tells a client that the server will not process a request because it might have arrived through replayable TLS early data. The client can retry that request after the relevant TLS handshake is complete, but the retry must not itself use early data. This is a specific HTTP safety mechanism from RFC 8470, not a generic signal that a server is overloaded or that an API request should be repeated indefinitely.
For an AI-agent tool gateway, the important question is whether an attacker could duplicate a request before the TLS 1.3 handshake finishes and cause a second effect. A harmless, read-only resource may tolerate replay. A request to trigger a purchase, send an email, write a record or start an expensive job usually requires a firmer boundary. Choose among disabling early data, deferring processing, or returning 425 with correct hop information; do not confuse ordinary authenticated transport with permission to perform an action.
This guide reconstructs that decision from the actual protocol rules, walks through a proxy-to-origin exchange, tests unsafe and apparently safe methods, checks request and retry denominators, diagnoses common failures, and provides an independent changed-condition exercise with answers. All example services, counts and timestamps are explicitly illustrative, not observations about any deployed agent. The relevant primary specifications are RFC 8470, RFC 8446 and the HTTP semantics in RFC 9110.
Contents and reader routes
For a short foundational route: What is TLS early data, and why does HTTP need another rule?; Exactly what an HTTP 425 response means; Read the handshake timeline from first principles; Compare the three standards-based protective choices; Safe HTTP methods are a clue, not an application guarantee; Understand the Early-Data request field at a proxy boundary. A reader should be able to explain the difference between early bytes, a completed TLS handshake and a real application effect before proceeding.
For gateway and client implementation: Trace one request across client, edge and origin; When an origin must use 425 and what it must not do; What a conforming client actually retries; Why proxy retries have extra constraints; Map real business effects before deciding what is replayable; Compare three concrete agent-tool calls; Worked example: count attempts and completed operations separately; Worked example: a claimed latency saving can hide duplicate cost. These chapters distinguish protocol-required behaviour from an operator’s optional mitigation choices.
For diagnosis, practice and deployment: High load changes the correct operational choice; Fleet consistency matters more than a single green test; Partial requests and out-of-order arrival; Troubleshooting 425 loops and missing retries; Keep replay policy separate from authorisation and identity; A practical change plan that does not lose safety on rollback; Independent transfer exercise: a hidden replay-sensitive GET; A small incident report with truthful units and uncertainty. Finish with frequently asked questions, primary technical sources and related verified eduKate reading.
What is TLS early data, and why does HTTP need another rule?
TLS 1.3 can resume a previously established connection using a pre-shared key. Under suitable conditions, the client may send application bytes optimistically with its first flight, before the server has finished authenticating the new handshake. This is conventionally called zero round-trip-time application data or 0-RTT. The name describes when a client can transmit; it is not a promise that every response arrives in zero network round trips.
The resumed secret supplies cryptographic protection, but early data lacks the same replay guarantees as ordinary completed-handshake application data. An attacker with a copied early-data flight may try presenting it to another accepting server instance. One machine might process a side effect while the original connection also succeeds. Neither an encrypted payload nor an authenticated prior connection automatically prevents that specific application-level duplication.
RFC 8446 includes anti-replay considerations for TLS early data, yet RFC 8470 explains why HTTP servers and clients need complementary policy. Even a transport that limits duplicate acceptance can operate behind a gateway whose other instances disagree about early requests. Whether replay is tolerable depends on the resource and side effect, not solely on a cipher suite or on a checkbox in a reverse-proxy configuration.
A reader should separate four moments: creation of a previous resumption ticket, a new ClientHello and early request bytes, completion of the new TLS handshake, and the moment the application starts acting on the request. The fourth moment is where a duplicate payment or state mutation can become real. A server can parse enough bytes to understand routing without committing any application effect.
Exactly what an HTTP 425 response means
The status number 425 is named Too Early. In this context the server is unwilling to risk processing a request that might be replayed. It does not mean that the request was sent before an appointment, that a scheduled API job should be postponed until tomorrow, or that the caller exceeded a rate limit. It is about the security of the request’s arrival and possible repetition.
RFC 8470 says a client that sent a request in early data should automatically retry on a 425 response, subject to the standard’s wording, and any resulting retry must not be sent in early data. A server should not emit 425 unless it has evidence that the request arrived as early data or carries the Early-Data request field. That qualification matters: a normal fully handshaken request receiving 425 may not have a meaningful automatic-retry path.
A 425 response is not cacheable by default and its content is not the representation of the identified resource. It is useful to log the response as a transport-stage policy decision, not as a permanent business failure. A gateway should not convert it into a successful tool invocation, drop the status code from an intermediary response, or pretend that the requested effect has happened.
The word retry is sometimes abused in distributed systems. A valid 425 retry is not blanket permission to repeat side-effecting application requests after an arbitrary timeout. If a client knows the server may already have processed a request, ordinary idempotency and duplicate-submission safeguards become necessary. The precise RFC 8470 condition is that replayable early-data requests are rejected before unsafe effects, allowing a safe later attempt.
Read the handshake timeline from first principles
Imagine an agent gateway already has a valid TLS 1.3 resumption ticket from an earlier connection. The client sends a new ClientHello and optimistically includes an HTTP request in early data. A server that supports this resumption may accept that early application data before the resumed handshake completes. This is a permitted protocol path, not an invitation to trust every instruction appearing in the request.
The edge can instead reject early data at the TLS layer. That is an all-or-nothing choice for that early-data flight, not a selective HTTP resource rejection. Alternatively the TLS layer may accept early data while the HTTP layer defers actual handling of a particular request until the handshake completes. Finally, the HTTP server may return 425 for a request it will not process early.
One crucial distinction is parsing versus acting. Reading request headers, validating syntax and determining routing can occur while deciding what to do, but a handler that debits an account, sends a notification or starts a costly task has already produced an effect. Calling that action preliminary work does not stop the effect from being replay-sensitive. Make the processing boundary explicit in source code and operations documentation.
When a client receives a proper 425, it can send the request again after the connection’s handshake is complete, or use a new fully established connection as the relevant client implementation permits. That new attempt is subject to ordinary authentication, authorisation and application policies. A successful retry must be counted as a new HTTP attempt, not silently merged with the rejected attempt when measuring protocol outcomes.
Compare the three standards-based protective choices
The first option is to refuse early data entirely. That gives up its potential latency benefit but avoids exposing HTTP handlers to its replay properties. For administrative endpoints or financial workflows it can be the simplest defensible setting. Refusing early data should not be confused with refusing all TLS resumption; the server may still use resumption without processing application bytes before the handshake is finished.
The second option is to accept the early-data bytes but delay their application processing until the handshake completes. The server may need bounded buffering and precise resource limits. RFC 8470 notes that the early-data extension’s max_early_data_size can constrain the amount the server risks committing to memory. The holding queue must not independently trigger application side effects before release.
The third option is to accept the early-data connection yet send 425 for a request the server judges too risky. That makes the decision visible at HTTP level and gives a compatible client a route to try later. A server might allow an inexpensive read-only lookup while rejecting a write operation on the same connection. The HTTP layer can decide by resource and configured replay tolerance.
None of the three is universally fastest or automatically correct for every endpoint. Choose using actual protocol support, replay consequences, client retry capability, proxy topology, side-effect inventory and load. If a deployment lacks consistent knowledge of which resources are safe to replay, the conservative default is to reject early processing rather than guess from a method name or hope the TLS library solves all downstream risks.
Safe HTTP methods are a clue, not an application guarantee
RFC 9110 defines method properties including safety and idempotence. GET and HEAD are designed for retrieval and should not request changes to server state, while POST commonly asks for processing that can produce effects. PUT and DELETE are described as idempotent in HTTP semantics, but idempotence is not identical to safety, and it is not a promise that an unaudited implementation avoids every incidental side effect.
RFC 8470 permits a client to send safe methods as early data when it lacks more specific information, but it must not send methods known or suspected to be unsafe. A client may have additional knowledge about a resource’s replay tolerance from protocol or configuration. A method label by itself cannot certify that a particular endpoint is free from state-changing side effects.
Consider a GET endpoint named /reports/export whose handler creates a paid archival job whenever it receives a request. Despite its GET name, that behaviour has a side effect and is not appropriate to trust merely because the method normally means retrieval. A duplicated request might generate two jobs. The right repair is to correct the resource design and avoid early effects, not to redefine HTTP safety through an informal naming convention.
Conversely, a carefully designed duplicate-tolerant operation may use an application idempotency key and an atomic record of already accepted work. That can make later retries more robust, but it does not automatically permit unsafe methods to be transmitted in early data contrary to the client requirements. Keep application repeat suppression and transport-stage early-data rules as complementary controls, not replacements.
Understand the Early-Data request field at a proxy boundary
The Early-Data header field defined in RFC 8470 communicates that a request might have passed through an earlier hop before its TLS handshake finished. It is a request field, not a response field or trailer. Its defined value is 1; the standard tells servers to treat multiple or invalid occurrences as if a single Early-Data: 1 were present rather than assume a malformed value makes the request safe.
A client initiating an early-data request does not need to set the header field merely because it used TLS early data. The edge knows it received early data from its transport connection. The field becomes especially important when that edge forwards a request to another HTTP server over a different connection. The origin otherwise might see an entirely ordinary established TLS connection and lose the information that the request arrived early elsewhere.
An intermediary that may have already forwarded a replayable early request must preserve that risk signal. RFC 8470 prohibits removing an Early-Data field from a request that already has it. It also prohibits including Early-Data in the Connection field, which might cause a hop-by-hop interpretation that discards the signal. These are protocol integrity requirements, not optional logging conventions.
The origin must not treat the arrival of a marked request over a now-completed backend TLS connection as proof that the original external request is safe. A request received with Early-Data can represent replay exposure on an earlier hop. Waiting for the origin’s own TLS handshake cannot undo that history. The origin must apply its replay policy and use 425 when the marked request cannot safely be processed.
Trace one request across client, edge and origin
Imagine a fictional browser connecting to gateway.example.test, an edge proxy that forwards to origin.example.test. The browser sends a read request in TLS 1.3 early data. The edge accepts the early bytes and forwards the HTTP request over an already-established internal TLS session. If forwarding might occur before the external handshake completes, the edge must communicate the risk by setting or preserving Early-Data: 1 as applicable.
The origin’s HTTP handler now sees the request and the Early-Data signal. It decides that the requested endpoint initiates an expensive export operation, so replay is not acceptable. Because the request is marked and cannot safely be processed, RFC 8470 requires it to be rejected with 425. The origin must not quietly enqueue the export and then return 425 as a convenient instruction to try again.
The intermediary forwards the 425 according to the relevant rules, and the initiating client then retries without early data. The origin processes the later attempt after the normal security checks. The visible protocol sequence includes at least two HTTP requests, even though only one should cause an export job. Merely observing one eventual successful response does not prove the rejected attempt had no effect.
If the edge intentionally prevents forwarding until its client handshake finishes, its handling still needs to match RFC 8470’s conditions. The edge must not misrepresent a request already flagged as early on a preceding hop. In a multi-proxy chain, each intermediary needs to preserve enough provenance for the final decision. The origin owns the resource-specific judgement; an uninformed middlebox should not invent it.
When an origin must use 425 and what it must not do
RFC 8470 is explicit about marked requests: an origin receiving an Early-Data request field for an operation that cannot safely be processed must reject that request using 425. Processing the unsafe operation and sending 425 afterwards would contradict the purpose of the response. The decision belongs at a stage before mutations, irreversible events or costly external calls.
An origin should not send 425 for an ordinary request unless it knows it arrived in early data or bears the Early-Data signal. Otherwise clients may not know how to recover. For example, a request that arrived after a fully completed handshake and contains no signal should generally receive a normal HTTP result or a status that accurately reflects the real problem.
Multiple incompatible retry mechanisms can create surprises. A generic client library may automatically retry 5xx responses; an HTTP-425 handler may separately retry requests, while an agent-level workflow engine may retry tool calls after network interruption. Without coherent attempt identifiers and a clear rule for which layer controls repetition, one intended operation can turn into several submissions.
The application should document whether a request was rejected before effect, accepted for processing, completed successfully, or has an unknown outcome. These are different states. 425 belongs to a narrowly defined pre-processing rejection and, when used correctly, is not a generic way to describe an unknown result. An unknown result requires its own reconciliation mechanism and may not be safe to repeat.
What a conforming client actually retries
A user agent that uses early data is expected to understand a 425 response. It should retry automatically in the standard’s terms, and any retry must not be sent in early data. If the server rejects the entire early-data flight at the TLS layer, the client also needs to restart any optimistically transmitted HTTP requests as though the connection were new, subject to the details of the resumed negotiation.
The precise client behaviour may depend on HTTP library support and the higher-level application’s expectations. A library that receives the status but displays it as an ordinary application error has not provided the same experience as a 425-aware client. Test whether the chosen runtime actually recognises early data, manages a later retry and preserves the original method, target and payload when suitable.
A client must not assume it can resend an arbitrary sensitive request after every timeout. With 425, the server is signalling it would not risk processing the replayable request; with a broken connection and no response, the client does not necessarily know whether the operation happened. Treat those conditions differently in retry policy. Otherwise an API may accidentally create duplicates while believing it is following the early-data specification.
For an AI assistant using an HTTP client stack, expose the distinction to the surrounding orchestrator. The assistant should not reinterpret 425 as permission to change payment details, widen an API scope or send a request to an alternative unverified endpoint. An allowed retry preserves the intended operation under application policy and passes through the usual authorisation guard again.
Why proxy retries have extra constraints
An intermediary may forward a 425 status code under all relevant conditions, but RFC 8470 adds a stricter forwarding requirement when the request that the intermediary received and forwarded carried Early-Data. The intermediary must forward the 425 in that case. It should not conceal the response by issuing an untracked duplicate of a request for which a downstream origin already saw the early-data signal.
When an intermediary itself received a request in TLS early data and later gets a 425 from a downstream server, it may be able to retry automatically. It must wait until the TLS handshake on the connection where it received the request has completed. This is not a rule saying that any internal network connection is sufficient; the external handshake that created the replay concern is central.
A multi-region reverse proxy complicates consistency. One edge may accept early data, another may reject, and a third may forward to a different origin cluster. RFC 8470 allows different mitigations but requires them to be consistent with avoiding unsafe early processing. A request that might be replayed must not cause one instance to mutate state while another rejects it and triggers a later retry.
A useful trace preserves a stable request correlation identifier across hops and distinct attempt numbers for the early attempt and later retry. That identifier is diagnostic, not a proof of exactly-once execution. A server-side idempotency ledger can address duplicate work separately, but the HTTP trace must still show whether the original marked request was processed and whether a 425 was returned.
Map real business effects before deciding what is replayable
Begin with the simplest side-effect inventory: reads that retrieve public or authorised records without mutating state; reads that increment a counter or charge a customer; writes that enqueue work; and operations that trigger downstream services. Classify each by what would happen if it were processed twice. A read-only endpoint can still leak information if the request is allowed under the wrong identity, so replay safety is not the only security check.
Suppose a scheduling assistant has endpoints for availability search, temporary holds, and confirmed bookings. A duplicate availability lookup may be acceptable if it merely reads authorised records. Duplicate temporary holds could tie up capacity. Duplicate booking confirmations could charge or reserve twice. These are resource-specific conclusions; method names, URL spelling and generic safe-method tables do not replace auditing what each handler actually does.
An expensive read is another important category. A request might not mutate a database but could consume GPU time, start a large inference task or exhaust a quota. RFC 8470 highlights denial-of-service risk from replayed expensive requests. Even where persistent state is unchanged, repeating substantial computations might harm availability or incur cost. Rate limiting alone does not establish replay safety.
Keep this inventory next to endpoint ownership, not buried in a TLS configuration guide. The team responsible for the resource knows whether a replay is tolerable. Gateways can enforce policy only when this knowledge is expressed through route configuration, service annotations or explicit allowlists. Where the knowledge is missing, it is safer to defer or reject early processing than to infer safety from happy-path tests.
Compare three concrete agent-tool calls
Case A is a hypothetical tool GET /catalog/items?page=2 that reads a cached public catalogue without side effects. Assuming authentication and confidentiality requirements are met, repeating it may be tolerable. A gateway might allow it in early data if it has verified resource-specific safety and the whole fleet treats it consistently. This is a design choice for the fictional service, not universal approval for every GET request.
Case B is POST /messages/send, which causes a service to deliver an email. A copied request can lead to two messages, and a delivery side effect cannot be undone by returning an error afterward. The safer options are not to send it in early data and to reject or defer any replayable incoming version before delivery. Application-level deduplication can additionally help with later non-early retries.
Case C is a model-inference endpoint that streams an answer and charges by work performed. The result is not merely a database read if every invocation consumes resources and advances billing. A duplicated early request may start two expensive generations. A route labelled inference therefore needs an explicit replay and quota decision; the words stateless model do not make processing harmless.
Now consider an agent orchestration layer that calls all three in sequence. It should not apply one blanket retry rule simply because each uses HTTPS. Catalogue reads, messages and inference jobs have different outcomes. TLS authenticates the peer; HTTP early-data policy limits a replay path; workflow policy governs user intent and authorisation. Treating those as separate layers is the practical lesson.
Worked example: count attempts and completed operations separately
Assume a fictional gateway logs 12,000 HTTP request attempts during a ten-minute test. Exactly 3,000 attempts arrive in TLS early data, and 9,000 arrive after completed handshakes. Within the 3,000 early attempts, 2,100 are judged safe reads, 600 receive 425 before any application effect, and 300 are deferred until handshake completion. These are stipulated counts rather than measured results.
The fraction of all attempts arriving in early data is 3,000 divided by 12,000, or 25 percent. Among early attempts, the share receiving 425 is 600 divided by 3,000, or 20 percent. Among all attempts, those 425 responses represent 600 divided by 12,000, or 5 percent. State the denominator every time: otherwise one dashboard can claim both a five percent and twenty percent rejection rate without explaining the different populations.
Suppose 570 of the 600 rejected requests are retried after the handshake, and each retry is counted as another HTTP attempt in a later log window. The observed retry completion rate for rejected requests is 570 divided by 600, or 95 percent, provided each rejected request can be matched to a later distinct attempt. It does not mean the original 600 requests succeeded, and it does not establish exactly-once business execution.
Suppose the 570 successful retry attempts each cause one permitted application effect while the original 600 cause none. The intended successful business-operation count is 570, not 1,170. The 30 without a matching retry are not automatically errors caused by TLS; callers may abandon them. Inspect outcomes, timing and request identifiers before drawing a conclusion. This arithmetic demonstrates why protocol-attempt counts and effect counts must remain separate.
Worked example: a claimed latency saving can hide duplicate cost
Consider an invented service that serves an endpoint with a normal completed-handshake setup delay of 40 milliseconds in one measured environment. Optimistically sending early data might save a portion of handshake waiting time for eligible resumed requests, but 40 milliseconds is a stipulated example, not a universal saving for TLS 1.3 or HTTP/3. The actual gain depends on network distance, tickets, protocol and server behaviour.
Assume 1,000 eligible requests in an illustrative cohort. Of these, 700 complete on their first allowed early-data path, 200 require a post-handshake retry and 100 take the ordinary handshake path. If the early-success path avoids the stipulated 40 milliseconds, the most optimistic arithmetic counts 700 times 40 milliseconds, or 28,000 milliseconds of aggregate avoided wait across requests. Aggregating time does not imply any one user saved 28 seconds.
That simplified number ignores extra waiting for the 200 retries, request processing costs, variable RTTs and losses, and the fact that no gain is realised for some paths. It cannot be used as a measured overall latency reduction. A proper evaluation reports request-level latency distributions such as median and high percentile and compares equivalent operations, with a separate count of retries and replay-related protection decisions.
Now suppose the unsafe path would start an expensive 500-millisecond computation twice if a replay were mishandled. Avoiding even a small number of duplicate jobs could matter more for resource use than a speculative 40-millisecond handshake saving. The computation values are fictional, so the comparison teaches a measurement principle rather than proving one option faster. Benchmark security outcomes and service cost, not only the handshake chart.
High load changes the correct operational choice
During severe load, accepting early-data requests and then individually generating responses can create work even when the server ultimately rejects unsafe effects. RFC 8470 notes that replayed expensive requests can expose a server to denial-of-service pressure. A server under load should consider rejecting TLS early data wholesale rather than spending additional resources on selective application handling.
Status codes can amplify the problem if they cause many clients to retry simultaneously. A 425 or 503 may prompt retries that increase pressure, while ordinary rate limiting or backoff policies answer different concerns. For 425 the essential property is that a proper later retry is not early data; this does not make infinite retries useful or safe. Coordinate client and gateway retry budgets with operational capacity.
Imagine four regional gateways each sees 500 early-data requests per second. If half of them receive 425 and all clients immediately retry, the environment may face an additional 1,000 retry attempts per second across regions, assuming identical steady rates. The numerator is 4 times 500 times 0.5, while the original traffic count remains 2,000 per second. This illustrative workload excludes time clustering and does not predict any real capacity limit.
A safer production investigation asks what portion of 425 responses was generated by genuine unsafe routes, how clients spaced retries, whether backend concurrency remained bounded, and whether all instances agreed on policy. Raising a global retry limit without establishing those facts may worsen the incident. A deliberate no-early-data configuration can be a valid recovery tactic when the service cannot safely absorb uncertain load.
Fleet consistency matters more than a single green test
RFC 8470 requires consistent handling of replayable early requests across server instances. Consistency does not mean every instance must choose the same exact mitigation: rejecting at the TLS layer, delaying application processing and returning 425 can all be acceptable. It means no instance may act on unsafe early data while another instance could make a conflicting decision about that same data.
Consider two deployment rings. Ring A has a policy that waits for completed handshakes on booking routes. Ring B has an older configuration that executes booking handlers immediately and relies on a later gateway check. A replay that reaches both can cause an unwanted side effect through B even if A correctly rejects it. A single canary handshake in A does not establish fleet-wide replay safety.
Check policy propagation as a data-consistency problem. Inventory edge nodes, routes, protocol versions, intermediary libraries and last-applied configuration fingerprints. Simulate the same replay-sensitive request arriving at each relevant tier. Verify that no path begins work early and that the Early-Data signal is not stripped on an internal hop. The objective is to prove the absence of an unsafe path, not merely find one healthy instance.
Network partitions and rolling deployment boundaries deserve explicit tests. During an update, some proxies may know a route is unsafe while others still consider it safe. Protect the resource at the origin in addition to configuring the first edge when possible. If the origin cannot recognise the early-data provenance, a deployment should not expose that route through an early-forwarding intermediary until the policy is corrected.
Partial requests and out-of-order arrival
An HTTP request need not arrive entirely before the TLS handshake finishes. Some headers or body bytes might be received in early data while the remainder arrives later. RFC 8470 points out that the important distinction is when processing starts, not the exact byte boundary at which the request becomes complete. Treat the whole request as potentially replayable if an unsafe portion could already have triggered action.
Parsing an incomplete request is usually different from carrying out its effect. A gateway might validate a Content-Length header, select a route or allocate bounded buffers without starting a purchase. But a streaming handler that dispatches a job when the first few body bytes arrive has already acted. Delaying only the final response will not reverse that earlier action. Record when the side-effect boundary is crossed.
HTTP/3 over QUIC introduces an additional ordering nuance. Streams and packets can arrive in ways that make completion order differ from simple chronological expectations. RFC 8470 recognises that early data may reach an application even after the handshake completes. A server can only process it safely when it can rely on consistent replay handling by other instances; the local wall-clock arrival time is not a complete security argument.
Tests should therefore include split headers, split bodies, several requests on one connection, aborts and reordered delivery where the transport permits it. The expected outcome for an unsafe early request is no application effect before a safe decision. This can be checked with an isolated fake downstream service that records invocation counts, rather than risking real customer data or external side effects.
Troubleshooting 425 loops and missing retries
If users report a 425 loop, inspect whether the client repeatedly sends the retry in early data. That would violate the requirement that retries after 425 not use early data. Check HTTP library and proxy versions, because a client and its intermediary may each think the other is responsible for removing early-data behaviour. The final decision should be evident from a hop-by-hop trace with sensitive details redacted.
If a server emits 425 for ordinary fully handshaken requests without an Early-Data field, investigate its request classification. The standard warns against sending this code unless the request actually arrived in early data or carries the field. Misclassification makes recovery ambiguous and may cause incompatible clients to retry unnecessarily. Fix the classification instead of encouraging every client to retry forever.
If a marked request succeeds through an unsafe route instead of producing 425 or being subject to a correct defer-or-reject strategy, investigate whether a proxy stripped the Early-Data field, whether the origin ignored it, or whether the handler changed. Recover the actual effect record before reproducing the call. A debugger must not trigger a second purchase merely to test the first suspected duplicate.
If only one region fails, compare early-data configuration, route ownership and deployment order against other regions. Capture TLS early-data acceptance, HTTP request field presence, returned status, request correlation IDs and application effect counts. A generic HTTP 4xx counter is not enough. Do not repair a 425 issue by disabling TLS certificate verification, widening tool permissions or suppressing audit logs.
Keep replay policy separate from authorisation and identity
Even a request safe to replay must be authorised for the particular user, tenant and resource. If a browser is allowed to view public documentation, the fact that the GET can be repeated does not authorise it to retrieve private files. TLS early-data acceptance and application authorisation enforce different properties. The TLS layer controls an early transport path; the app checks what the caller may do.
An AI-agent gateway may use tokens, workload identity, signed requests or an approval workflow. None of those alone guarantees the operation is safe when repeated. A perfectly authenticated POST can still schedule two jobs. Conversely, an inherently safe GET can be an unauthorised disclosure if a token is missing or accepted for the wrong audience. Treat authentication, replay control, rate limits and action approval as parallel checkpoints.
Suppose an assistant’s tool call is to close a customer account. It must pass ordinary user and agent permissions, but replay exposure adds a second question: could the same approved request be executed twice by an attacker or by layered retries? Disable early processing for such actions, enforce clear workflow state transitions and use a durable duplicate-operation guard when appropriate. These choices are specific to the business operation.
The article’s series title concerns modern agent systems, not a claim that artificial superintelligence exists. TLS 0-RTT and HTTP 425 are established networking mechanisms that can be used by applications containing ordinary AI agents. Their correctness is an engineering matter, and they cannot infer whether a model’s proposed action is wise, lawful, truthful or consistent with user intent.
A practical change plan that does not lose safety on rollback
Before enabling early data, list the routes that could receive it, the origin services that may process it, and the possible irreversible effects. Give each route a named owner and an explicit classification. Disable early processing by default for unknown routes. Confirm that the TLS library, reverse proxy and application framework support the relevant protocol semantics rather than assume they all share one setting.
During rollout, choose a deliberately harmless read-only canary endpoint and verify behaviour using a client capable of early data. Then test a replay-sensitive endpoint in an isolated staging environment: the early attempt must be rejected or deferred appropriately, and the subsequent correct retry must occur after handshake completion. Check that only one intended effect can occur. Keep logs of attempts and effects separate.
Test all proxy hops, including an origin receiving Early-Data: 1 over an ordinary established internal connection. The origin must not erase that signal or infer safety from local transport completion. Also exercise clients that never support early data. They should continue working by normal HTTPS paths without receiving inappropriate 425 responses. A safe migration respects legacy behaviour as well as new features.
Plan rollback before launching. If a route’s replay classification proves wrong, disable early data or enforce application deferral while leaving normal full-handshake TLS available. Roll back policy consistently across regions, verify the new behaviour and investigate already-executed effects before re-enabling. Do not conceal an incident by dropping 425 metrics or treating failed handshakes as the absence of a problem.
Independent transfer exercise: a hidden replay-sensitive GET
Consider a new fictional education API. GET /timetable reads a timetable and has no side effects. GET /download-certificate creates a paid signed PDF and sends an email each time it is called. POST /lesson-booking creates a reservation. A TLS 1.3 edge allows early data and forwards requests to an origin over an established connection, preserving Early-Data: 1. The origin sees all three routes with that field.
Question one: which requests should the origin process in early data with no extra knowledge? Question two: if it cannot establish replay tolerance, which signal should it return for the latter two? Question three: if the browser retries a returned 425 before the edge handshake completes, is that conformant? Finally, explain how your policy changes if the download handler is redesigned to return an already-stored immutable file with no billing or email effect.
The appropriate first answer is to treat only /timetable as a candidate for early execution after checking actual authorisation and implementation details. The so-called GET download creates paid work and email, so its HTTP method is not a reliable safety proof. The booking POST is also replay-sensitive. With Early-Data present, an origin that cannot safely process those marked requests must reject them with 425 rather than execute the effects.
A client retry after 425 must not use early data, so the proposed pre-handshake retry is not conformant. After redesign, /download-certificate might become replay-tolerant if it truly only retrieves a cached immutable authorised file and does no expensive or stateful action; permissions and resource costs still deserve verification. The changed-context lesson is that behaviour of the actual resource, not the method label, determines replay tolerance.
A small incident report with truthful units and uncertainty
Imagine a staged replay test involving 200 authorised requests to a safe read endpoint and 40 to an unsafe staging booking endpoint. Each request is transmitted in an early-data scenario with test harness support; this does not imply that any real customer booking exists. The test’s acceptance criterion is no booking mutations before an appropriate completed-handshake path and appropriate 425 or deferral handling for unsafe traffic.
Suppose the test records 40 early booking attempts, 40 responses of 425, and no booking mutations from those attempts. The early booking rejection rate is 40 divided by 40, or 100 percent. That alone does not show whether all clients later recover. If 38 requests are later retried properly and each creates one intended staging booking, the post-handshake retry completion rate is 38 divided by 40, or 95 percent.
If the harness can reconcile exact attempt IDs, the two missing retries are unresolved client behaviour, not evidence that the original 425 path secretly succeeded. An audit should check whether the client abandoned those requests, lost network connectivity or failed to understand the status. It should not convert a missing retry into a fictitious server-side effect. Keep per-attempt HTTP outcomes distinct from per-intent business outcomes.
To make the report credible, include the TLS version, edge and origin library builds, replica count, policy revision, routes exercised, clock bounds, request identifiers, observed mutations and limitations. The numerical story here is invented and intended as a template for arithmetic, not an external performance claim. Independent reproduction and real instrumentation are needed before anyone can draw conclusions about a production service.
Frequently asked questions
What is the difference between HTTP 425 and 429?
425 concerns a possible replay of a request sent via early data and guides a later non-early retry. 429 Too Many Requests instead communicates rate limiting. Their retry semantics and server conditions are not interchangeable, and a tool agent should not reinterpret one as the other.
Can a client retry a 425 inside another TLS early-data flight?
No. RFC 8470 requires that retries following 425 not be transmitted in early data. The client must move to an appropriate completed-handshake path. A library that repeats the same early-data request automatically is precisely the class of behaviour operators need to detect.
Is GET always safe in early data?
No. GET is defined as safe by HTTP semantics, but some implementations have side effects or expensive execution. A resource owner must determine actual replay tolerance. Requests still require proper access control even if repetition produces no application mutation.
Does an Early-Data field mean that the immediate TLS connection is unfinished?
Not necessarily. It can mark a request that originated as early data on an earlier hop, even when the origin receives it through an ordinary already-established connection. Waiting for the origin connection to finish cannot undo the earlier replay exposure.
When is an origin required to return 425?
For a request carrying the Early-Data field that cannot safely be processed, RFC 8470 requires rejection using 425. Other mitigations such as disabling early data or deferring an unmarked locally received early request depend on how the request reached the server.
Can application idempotency keys replace the protocol rules?
No. They are a complementary protection against duplicate business effects. They do not remove client restrictions on unsafe methods in early data, proxy obligations to preserve the Early-Data signal, or the requirement that any retry after 425 avoid early data.
Does 425 mean the original business action definitely failed?
A correctly implemented 425 path indicates the server refused to risk processing that early request. However, observed implementations can be defective and distributed logs may be incomplete. For high-impact operations, reconcile effect records rather than treating a raw HTTP status as proof of exactly-once execution.
What is the simplest safe option for uncertain routes?
Do not process their requests as early data. Reject early data at TLS level or delay application processing until an appropriately completed handshake, while ensuring intermediaries preserve the risk signal and all replicas are consistent.
Does using TLS 1.3 automatically mean 0-RTT is enabled?
No. TLS 1.3 supports resumption and an early-data facility, but practical use depends on both endpoints, ticket configuration, protocol support and server policy. A service can run TLS 1.3 without accepting any early application data.
What should an AI-agent operator measure?
Record how many requests actually arrived in early data, how many carried an Early-Data field, how many received 425, how many retries completed without early data, and whether any unintended application effect occurred. Use denominators by request attempt and by intended operation separately.
Primary technical sources and evidence boundaries
The normative HTTP early-data behaviour, Early-Data request header and 425 Too Early response are defined in IETF RFC 8470, Using Early Data in HTTP (September 2018), especially Sections 3 to 6. Its explanations address client retries, proxy forwarding, resource-specific processing, replay and server consistency. This source documents a protocol specification, not a measured success rate for an agent deployment.
The underlying transport is IETF RFC 8446, The TLS Protocol Version 1.3 (August 2018), including its early-data and anti-replay discussions. The existence of TLS 1.3 does not, by itself, establish that an individual client and server negotiated early application data.
Method safety, idempotence, HTTP status handling and request semantics are treated in IETF RFC 9110, HTTP Semantics (June 2022). RFC 9110 explains the meaning of safe and idempotent methods; it is not a substitute for auditing a specific service’s real effects. Original numerical cases here are fully illustrative and hand-checkable.
A reader implementing this feature should inspect the particular runtime’s TLS library and reverse proxy developer documentation in addition to the RFCs, then test its actual behaviour in an isolated environment. The examples do not represent live packet captures, vendor certifications, measured security outcomes or a claim that any user-facing eduKate gateway has enabled TLS early data.
Related verified eduKate specialist reading
The How Super Intelligence Works hub collects explanations of real-world systems used around models and autonomous task software. This series discusses the engineering of those systems; the term does not imply artificial superintelligence has been created.
For a separate HTTP proxy concern, read Agent CONNECT-UDP Tunnels — MASQUE Datagrams, Target Rules and Proxy Safety. It explains tunnel targeting and proxy safety rather than the distinct RFC 8470 425 and early-data retry mechanism.
For TLS certificate authentication instead of replayable HTTP resumption, read Agent TLS Delegated Credentials — Short-Lived Keys, Client Negotiation and Expiry. A short-lived authentication credential and a safe 0-RTT application operation are separate concepts.
The final independent task is to classify a real service’s routes by replay consequences, identify every gateway that can receive early bytes, run staging tests that prove unsafe early requests produce no effect, and record matching post-handshake retry attempts with explicit denominators. Where an operator cannot establish those facts, leaving early-data processing disabled is an appropriate engineering conclusion.