Summary

  • An active HTTP working-group draft proposes 419 Purpose Declined for a request refused because of its declared Sec-Purpose. It is a one-request admission receipt, not a permanent ban, a server-health verdict or a new refusal capability; on 29 September 2026, IANA still listed 419–420 as unassigned.
  • The useful boundary is operational rather than cosmetic. Origins and authorized gateways need to preserve purpose, policy, cache behavior and later user demand through logs, SDKs, SLOs and alerts. Otherwise a new wire code is merely collapsed into another generic error and the dashboard keeps telling the wrong story.

At 09:17 the error graph rose sharply. The origin’s CPU was steady. Queue depth was ordinary. The health checks kept passing and immediate page requests were being served. The new traffic came from speculative fetches: clients were asking for resources that they expected might be needed soon, before a reader had actually navigated to them. The service had a local rule that declined some of those wagers when their likely value did not justify the work.

The rule was functioning. The graph was not lying about the bytes on the wire, but it was lying about their meaning. The server used 503 Service Unavailable for a deliberate admission decision, so the monitoring system counted healthy refusal as unhealthy service. An on-call team looking only at the aggregate had to investigate an outage that had not occurred.

draft-ietf-httpbis-pre-denied-01, dated 9 September 2026, proposes a narrow repair. It defines 419 Purpose Declined for a server that refuses a request because of the request’s declared purpose. The document is an active HTTP working-group Internet-Draft intended for the Standards Track. It is not an RFC. The IANA registry still marked codes 419–420 as unassigned when this evidence packet was frozen. The number is therefore a proposal, not a production fact.

That uncertainty does not make the design question trivial. The draft exposes a problem that already exists: systems often use one error vocabulary for two different realities. One reality is incapacity—the server cannot fulfil an apparently valid request. The other is choice—the server can respond but declines to spend resources on a speculative purpose. When those events share a label, operators cannot tell which control surface moved.

The request declared a purpose, not a destiny

The Fetch Living Standard defines the Sec-Purpose request header for purposes other than immediate use by the user. Its only defined token is currently prefetch: a resource is fetched because the client anticipates that it may be needed shortly. When Fetch processes a request whose initiator is prefetch, the algorithm sets Sec-Purpose: prefetch.

That declaration is useful precisely because it is limited. A server may adjust the cache expiry for a prefetch, disallow it or count it differently from a page visit. The header gives an origin a fact about the request’s initiating context. It does not prove that a person will later navigate, that the prediction is good, that the sender has a particular identity or that the bytes will improve a user-visible result.

The difference matters when resources are scarce or incentives diverge. A client optimizes perceived latency. An origin pays for compute, data access and egress. A CDN may carry part of that cost under a separate contract. A publisher may count visits, an advertiser may care whether a page was actually viewed, and a security system may treat speculative execution differently from direct demand. Sec-Purpose does not settle those interests. It makes one of them visible enough for a local decision.

Purpose is therefore an input to admission, not authority over admission. The client can say why it is asking. The origin or a gateway acting on the origin’s behalf decides whether that purpose deserves service now. This is a thin coordination rule: declare the context, return a scoped result, leave the policy with the actor that bears the cost and risk.

Why 503 and 403 distort the control surface

RFC 9110 gives 5xx a clear class meaning: the server failed to fulfil an apparently valid request. A 503 spike naturally points an operator toward capacity, maintenance, upstream dependency or another service-side fault. That inference is reasonable when 503 means what the class says. It becomes expensive when the same code is also used to decline speculative work while the service remains available for immediate demand.

The draft notes that this practice has caused confusion. The human consequence is familiar: alert thresholds fire, incident channels open, error budgets burn and teams search the service for a failure. The accounting consequence can be worse. A monthly availability report may treat a policy success as downtime. Capacity planners may add infrastructure to eliminate a graph that was created by intentional restraint. A customer contract may receive an error-rate number whose numerator mixes outages with requests the service never promised to accept.

403 Forbidden does not solve the problem cleanly. It suggests that access to the resource or action is forbidden. But a purpose refusal is narrower. The same target may be available moments later for immediate use, or the next prefetch may be accepted under different local conditions. Calling the resource forbidden invites a different but still inaccurate operational story.

The proposed 419 says only that this request was declined because of its declared purpose. It adds no ability to refuse. Servers already have that ability. Its contribution is legibility: the response can disclose which local decision occurred without pretending the whole service was unavailable or the resource was generally forbidden.

This is a good example of Minimum Initial Specification. The protocol does not need to standardize the operator’s cost model, prediction threshold, customer tier, origin load rule or business rationale. It needs a small shared distinction between service failure and purpose-based refusal. Later policy remains local and reviewable.

One request, one receipt

The draft is explicit that 419 applies only to the associated request. A future request with the same declared purpose might succeed or fail. This prevents a transient admission result from becoming a durable claim about the resource.

That sentence carries much of the design’s value. A prefetch declined at 09:17 under one load, cache and policy state does not authorize a cache, client or monitoring system to assume refusal at 09:18. An immediate-use request is a different operating fact. Even another prefetch may arrive after the resource is warm, the prediction model changes or capacity becomes available.

The draft therefore says 419 is not heuristically cacheable and that responses with this status should not be cacheable. A refusal is not a reusable representation of the target. If a cache stores and replays it as durable state, the admission decision escapes the actor and moment that justified it. Speculation would then be denied by yesterday’s answer rather than today’s policy.

The response is also not intended for display. It should carry zero-length content, and any content sent should be discarded. That is not merely a bandwidth preference. It prevents a machine-facing admission receipt from becoming a new error page, explanation channel or content surface. The useful evidence belongs in status, request context and operational logs—not in prose that a speculative client was never meant to show.

An implementation still needs to prove this boundary. Capture the cache-control fields. Send the same prefetch twice under changed conditions. Follow it with an immediate-use request. Confirm that no cache reuses the refusal, that the later request reaches the appropriate decision point and that client code does not surface an empty machine response as a user-visible failure.

The right to emit 419 is itself scoped

The draft permits an origin server and a gateway acting on its behalf—such as a CDN or reverse proxy—to generate 419. A proxy that is not acting for the origin should not. This is an authority rule hidden inside what looks like a status-code proposal.

The distinction matters because an intermediary sees traffic but does not automatically own the service’s admission policy. If an unrelated forward proxy can manufacture a trusted Purpose Declined response, it can erase a request before the origin applies its own rule. The wire receipt would then falsely attribute a decision to the service boundary.

Operational evidence should identify the decision owner. Was the result produced at the origin, an edge function controlled by the origin, a contracted CDN rule or an unrelated network intermediary? Which policy version ran? Which request fields were available? Was the edge authorized to decide for that target and purpose? The status alone cannot answer those questions.

This is where identity and authority must remain separate from purpose. Sec-Purpose: prefetch describes an initiating context; it does not authenticate the sender. TLS can protect a connection and other controls can identify a client or gateway, but the purpose header does not inherit those properties. Likewise, a CDN’s ability to serve cached bytes does not by itself prove authority to change admission semantics. That authority comes from configuration and contract, not proximity to the request.

The draft’s security note adds another boundary: the code might leak information about internal server state. A service that varies purpose refusal with load, inventory or policy could expose a new observation channel. The answer is not to blur the code back into 503. It is to decide how much policy granularity should be observable, rate-limit probing where appropriate and avoid letting the presence or timing of 419 reveal sensitive internal thresholds.

Unknown clients retain a class, not the explanation

HTTP status codes are extensible. RFC 9110 requires a client that does not recognize a specific status to understand its class and treat an unknown 4xx code as equivalent to 400 for general behavior. That gives a proposed 419 a safe compatibility floor: old clients can still see a client-error-class response.

The floor is not semantic preservation. An SDK may reduce 419 to bad request. A CDN log schema may bucket it as other 4xx. A retry library may apply the same rule as it does to malformed input. A dashboard may color every non-2xx response red. A tracing exporter may retain the number but drop Sec-Purpose. Each component remains technically operational while the distinction disappears.

Running-Code Primacy asks the harder question: did the deployed chain preserve the meaning that justified the new code? Test the actual browser or client build, edge, origin, cache, log collector, tracing pipeline, SDK, alert rule, error-budget calculation and customer report. A registration entry cannot repair those components by itself.

Purpose-aware systems need at least three dimensions: whether the request declared a speculative purpose, which decision point returned the response and whether the later immediate-use demand succeeded. Counting 419 separately from 503 is necessary but insufficient. If 419 rises because a client has started prefetching aggressively, the service may be healthy while the prediction policy has changed. If immediate-use failures rise at the same time, a real incident may still exist beneath the cleaner classification.

Do not solve one aggregation error by creating another. “All 503 is outage” was wrong when 503 carried deliberate refusal. “All 419 is harmless” would also be wrong. A forged, misconfigured or overly broad purpose-refusal rule can damage users. Classification says what decision was reported; it does not certify that the decision was wise.

Build the evidence join, not just a new counter

A useful receipt begins with the request: identifier, method, target, initiating context, Sec-Purpose, client build and relevant cache state. It then records the decision surface: origin or gateway identity, authorization relationship, policy version, evaluated rule and time. The response record includes status, cache controls, content length and trace position. Finally, it joins the later reality: whether immediate user demand arrived, how that request was handled, latency, bytes and origin work, and any user-visible outcome.

Without that join, the operator can answer only that some code appeared. It cannot tell whether speculation was wasteful, whether the refusal reduced work, whether a later navigation paid a latency cost or whether the same target was healthy for direct use. The proposed code improves the vocabulary of observation; it does not manufacture outcome evidence.

The most important counterfactual is the later immediate-use request. If no reader ever asks for the resource, refusing the prefetch may have avoided work—but exact savings still require a cost model. If a reader asks moments later and receives the page normally, the service-health distinction is proven while a latency trade-off remains. If the direct request also fails, the earlier 419 does not erase the incident. If the direct request is wrongly served a cached 419, the implementation has violated the intended request scope.

SLOs should state which population they measure. Availability for immediate user requests is not the same as acceptance of speculative requests. A separate prefetch-admission measure can track how often prediction is accepted without treating refusal as downtime. The two populations can then be correlated rather than collapsed.

The same discipline applies to security automation. A surge in 419 might reflect a browser release, an application adding prefetch hints, an attack that labels requests as speculative or an origin policy change. The code narrows the investigation, but the response still needs attributable request and policy evidence. Automation may route the alert to capacity, product, edge-policy or abuse teams only after those dimensions are present.

What the draft proves—and what it does not

The September draft proves that a working-group document proposes the 419 semantics described here. The Datatracker proves its process state. IETF 125 minutes record strong support for adoption of the earlier proposal. The Fetch specification proves how Sec-Purpose and prefetch are defined. RFC 9110 and RFC 9111 provide the surrounding HTTP and caching rules. The IANA registry proves that 419–420 remained unassigned on the freeze date.

None of those sources proves that a named browser sends the header in every relevant path, that a named CDN supports 419, that an origin deploys it, that monitoring software classifies it correctly or that it saves money. They do not prove a reduction in latency, egress, compute or incidents. They do not show how often a declined prefetch would have been used.

Those are deployment questions. They need implementation matrices, controlled requests, traces, cache experiments, policy records and observed user outcomes. The distinction between specification and evidence is especially important for a code whose purpose is to improve observability. It would be perverse to treat a clearer label as proof that the underlying system behaved clearly.

The draft is valuable because it stays small. A server can already refuse speculative work. The proposal lets that refusal identify itself without masquerading as incapacity. It limits the answer to one request, keeps it out of caches, avoids user-facing content and scopes who may generate it. That is enough common machinery.

The rest belongs to running systems. Preserve the declared purpose. Preserve the authorized decision point. Preserve the non-cacheable scope. Teach clients and dashboards the new classification. Join it to later demand. Only then can an operator say, with evidence, that the server was healthy and the refusal was intentional.

Sources