Summary

  • draft-ietf-httpbis-pre-denied-01 proposes 419 for a server refusing one request because of its declared Sec-Purpose; the indication is limited to that associated request, and a later request with the same purpose may succeed.
  • The code can improve operational classification by keeping a purpose-based refusal out of 503 outage telemetry, but it does not identify the internal policy, prove origin generation, authenticate human intent or establish future availability.

The incident board showed a vertical red line at 09:14. Hundreds of responses previously counted under 503 had moved into a new bucket marked 419. The on-call summary said “purpose-denial failure,” the availability graph fell, and an automated responder began draining traffic from a healthy region.

Nothing in the proposed status justified that sequence. The requests were speculative fetches. A gateway acting for the origin had declined them because their declared purpose made the expected benefit too small. Ordinary navigations continued to succeed. The metric was real; the outage was invented by the system that interpreted it.

Revision 01 of The Purpose Declined HTTP Status Code was published on 9 September 2026 as an active IETF HTTP Working Group Internet-Draft intended for the Standards Track. It expires on 13 March 2027. At the evidence freeze, 419 was not assigned in the IANA HTTP Status Code Registry. The proposal is work in progress, not an RFC, registration receipt, deployment survey or interoperability result.

Its importance is not the number. It is the discipline of naming a narrow decision without claiming the rest of the system.

Classification does not create authority

The draft starts from speculative requests. The Fetch Standard allows a user agent to declare a request purpose through Sec-Purpose, including a prefetch context. A server might conclude that sending the full representation will not improve performance and could impose negative effects. Today, operators can see 503 or another broad refusal code and infer a service problem that did not occur.

The proposed 419 says that the server is refusing the associated request because of its declared purpose. It introduces no new refusal capability. The recipient could already decline the request; the proposal gives that decision a more legible label.

That distinction matters because names often acquire imagined power. A status registry defines semantics for communication. It does not authorize a gateway, prove a policy lawful, establish a user's intent or compel the origin to make the same decision. The actor still needs authority from its actual role. The status only reports the reason that actor chose to present.

A clean event record therefore needs more than status=419. It needs the request method and target, the received Sec-Purpose, time, connection, responding hop, whether that hop acts for the origin, cache path, relevant policy revision and later ordinary-navigation result. Without those fields, the number is a label detached from the decision that gave it meaning.

One request is not a standing rule

The strongest limiting sentence in the draft is temporal: the indication applies only to the associated request. Future requests with the same purpose might succeed or might not. The status cannot safely populate a durable rule such as resource_blocks_prefetch=true.

Conditions can change between attempts. Cache state may change. Load may fall. A gateway rule can be updated. The target can vary its representation. The same declared purpose can arrive through another authorized path. The next request can also fail for a reason wholly unrelated to purpose.

This does not make the first response unreliable. It defines what the response reliably supports. The client received a refusal classified by declared purpose at a particular time and decision point. That is useful for suppressing a redundant retry, adjusting speculative-fetch policy or measuring how often speculation is declined. It is not evidence of permanent resource behavior.

The difference resembles the divide between a receipt and a title. A receipt records one transaction. It does not transfer ownership of every future decision. Systems become brittle when they promote event evidence into standing authority merely because the event was machine-readable.

Purpose metadata is not human intent

Sec-Purpose describes the request context chosen by a user agent. It can tell the receiver that the request is speculative. It does not authenticate a person, prove that a human asked for the resource, establish consent to a commercial action or predict that navigation will occur.

A browser can prefetch under its own heuristics. An application can form the field incorrectly. An intermediary can preserve, remove or process metadata according to its role and protocol obligations. Even when the value is syntactically correct, the evidence remains about the declared request purpose, not the inner intention of a user.

This boundary prevents two opposite mistakes. The server should not treat prefetch as proof of malicious automation. The client should not treat acceptance of a speculative request as proof that a later user action is authorized or complete. Purpose can inform resource policy while identity, consent, authorization and outcome remain separate controls.

The generator may be a delegated gateway

The draft allows origin servers and gateways acting on their behalf, including CDNs and reverse proxies, to generate the proposed response. A proxy not acting for the origin should not generate it. That rule makes the relationship of the responding hop part of the evidence.

If a CDN returns 419, the receipt supports the proposition that the delegated gateway classified and declined the request. It does not prove that origin application code evaluated the purpose, that the origin was overloaded or that every other gateway would make the same choice. Conversely, because an authorized gateway can legitimately enforce policy for the origin, calling the result “merely a proxy error” can also be wrong.

Operational systems need a decision-point lineage. TLS endpoint, connection coalescing, routing layer, Via information where available, Proxy-Status, cache diagnostics and provider configuration can narrow where the response arose. None should be promoted beyond its producer's authority. Proxy-Status can report intermediary processing; it cannot certify origin health. An origin log can show no matching request; it cannot by itself prove which earlier hop generated the response.

The right conclusion is bounded: identify the most specific actor the receipts support, and preserve uncertainty where they do not.

A better status can still produce bad availability numbers

The proposal exists partly because 503 carries operational meaning. RFC 9110 describes 503 as temporary inability to handle a request due to overload or scheduled maintenance. A purpose-based speculative refusal is not evidence of either. Separating it can make service-health telemetry more accurate.

But reclassification is not the same as improvement. If a monitoring system counts all non-2xx responses as availability failures, moving events from 503 to 419 changes no decision. If a dashboard removes 419 entirely, it can hide a sudden policy change that harms navigation warm-up, origin load or user-perceived latency. The status needs its own denominator and outcome links.

Measure at least three things separately: transport and service availability; the fraction of purpose-marked requests declined; and the effect of those decisions on later ordinary navigations. The first asks whether the service could respond. The second asks how the policy treated a request class. The third asks what users experienced. One event can contribute evidence to each, but it cannot collapse them into one truth.

This is the leadership value of narrower semantics. It does not eliminate judgment. It gives judgment cleaner inputs.

Request-scoped refusals must not escape through caches

The draft says the proposed status is not heuristically cacheable and should not be cacheable. The reason follows from its scope. Reusing a refusal can make a decision about one request appear to govern another request that the server never saw.

RFC 9111 defines the circumstances in which caches can store or heuristically reuse responses. A cache that treats every 4xx as reusable invents policy. Even when a response arrives with cache metadata, an implementation has to reconcile that metadata with the proposed requirement and with the semantics of the associated request.

Cache observability also needs two receipts. Cache-Status can describe whether a cache forwarded or reused a response. The 419 code describes the presented refusal classification. Neither proves the hidden reason the policy engine used, and neither establishes the future response. When a repeated refusal appears, investigators should first determine whether a new decision occurred or an old response was replayed.

The response body is not the authority

The proposal says these responses are not intended to be shown to a user. They should carry zero-length content, and content that is sent should be discarded. That protects the semantic boundary: automation should not parse an arbitrary HTML explanation and treat it as a stable machine contract.

It also reduces a tempting source of false precision. A body might say “capacity low,” “prefetch disabled” or “try later.” Those sentences can come from a generic error template, a misconfigured edge or an attacker controlling an intermediary. The proposed status says only that the request was refused based on its declared purpose. Extra claims need separately defined, authenticated evidence.

The security section adds another caution: the code could leak information about internal server state. If emission changes with feature flags, cache warmth, inventory or capacity thresholds, an observer may infer more than the operator intended. A narrow code improves legibility for authorized operations while also increasing the precision available to an external probe.

Sources and limits

The frozen evidence set contains revision 01 in HTML and text; its Datatracker status, history and references; the HTTP Working Group record; the Fetch Standard; RFCs 9110, 9111, 9209, 9211, 2119 and 8174; and the IANA HTTP status registry. These sources establish the proposal, the current registry state and the relevant HTTP boundaries.

They do not establish adoption, production behavior, a real outage, a vendor implementation or consensus that the draft will become an RFC. The opening incident is a constructed operating scenario. Its purpose is to test the inference chain, not to imply that a named service emitted 419.

Sources