Summary

  • HTTP/2 made one persistent, multiplexed connection eligible to carry requests for several URI authorities when DNS and certificate evidence supported reuse. That eligibility did not prove that every covered origin was configured behind the connection context selected at the first handshake.
  • 421 Misdirected Request lets an origin server, or a gateway acting for it, reject that origin–connection pairing without claiming that the URI moved, the request was malformed or the certificate necessarily failed. The client may retry the same operation over a different connection, even when the method is not idempotent.
  • RFC 8336 later allowed HTTP/2 servers to advertise an Origin Set before a failed request and required an implementing client to remove an origin from that connection's set after 421. HTTP/3 retained the status over QUIC, showing that the durable issue is authority under connection sharing, not a quirk of TCP.

One good connection invited a second name

Suppose a client has already opened an encrypted connection for one website. The endpoint is alive. The handshake has succeeded. The server has presented a certificate whose identity list also covers a second website. Name resolution gives the client reason to believe that the second site can be reached at the same endpoint.

Opening another connection would repeat work. Reusing the first one could avoid setup latency, conserve transport state and let the second request share a channel already doing useful work. HTTP/2 was built to make this kind of concurrency valuable. Several request streams could travel independently over one persistent connection instead of waiting behind a succession of new ones.

The reuse decision appears almost self-evident. The channel reaches the right machinery, and the credential recognises the right name. Why not send the second request?

Because the first handshake may have selected more than encryption. Its Server Name Indication may have selected a virtual service, a TLS termination policy, a customer partition or an origin backend. The certificate can describe several names while the particular internal route chosen for this connection serves only one of them. The network evidence may justify the client's attempt without compelling the receiving deployment to accept it.

HTTP needed a response for that precise disagreement. The result was 421.

Host named the target; it did not settle every route

The earlier history of HTTP had already separated a connection address from a named resource space. Once many websites shared one IP address, an origin could no longer infer the intended site from the TCP destination alone. HTTP/1.1 made the Host field mandatory so each request carried the host and port of its target. HTTP/2 and HTTP/3 ordinarily carry the same authority information in :authority.

That solved an identification problem: which origin does this request mean? It did not abolish the server's routing problem: is this origin configured here, and is the context of this particular connection suitable for it?

Current HTTP semantics preserve both sides. The request target's host and port distinguish one origin namespace from others a server might control. After receiving enough of the request to identify its target URI, however, the server still decides whether it can process the request itself, forward it, redirect it, reject it or close the connection. It must check scheme-specific requirements and the connection context instead of assuming that a parsed authority string makes every internal route valid.

Host therefore expresses the client's intention. It does not issue a command that every process reachable through the socket must speak for that name.

HTTP/2 made the inference worth attempting

The original HTTP/2 specification, RFC 7540, was published in May 2015. It encouraged persistent connections and allowed a connection to an origin server to be reused for requests bearing different URI authority components when the server appeared authoritative.

For an unencrypted TCP connection, the rule depended on the additional host resolving to the same IP address. For HTTPS, the certificate also had to be valid for the new host under the checks the client would have performed when opening a fresh connection. One certificate could establish authority evidence for multiple origins through several subject alternative names or an applicable wildcard.

Those conditions were a practical client-side test. They kept reuse from becoming a blind assumption that any endpoint could answer for any name. Yet they could not see the whole deployment behind the endpoint.

RFC 7540 gave a concrete failure mode. A middlebox might terminate TLS and use the SNI value supplied when the connection was established to select an origin server. A later request for another certificate-covered authority could then travel over the existing connection to a server context that was not the intended target. The certificate was not necessarily counterfeit. DNS was not necessarily poisoned. The request was not necessarily malformed. The client had made a reasonable inference from incomplete evidence.

The receiving side possessed the missing fact: this request did not belong on this connection.

421 was a refusal of pairing, not of existence

RFC 7540 introduced 421 Misdirected Request for that case. The current definition now lives in RFC 9110 rather than the HTTP/2 document. It says that the server is unable or unwilling to produce an authoritative response for the target URI. The target might not match any origin configured there, or it might not match the context over which the request arrived.

The scope matters. The response does not say that the resource is gone. It does not say that the origin has moved. It does not require the client to invent a new URI. It says that the route embodied by this connection has reached a context that declines to speak authoritatively for that target.

An origin server can make that judgment. So can a gateway acting on behalf of the origin, because such a gateway participates in the origin's serving boundary. A generic proxy cannot. RFC 9110 states that a proxy must not generate 421.

That prohibition keeps the negative evidence attached to the authority whose configuration it describes. If an arbitrary forwarding hop could manufacture the response, the client would not know whether the origin rejected the connection context or an intermediary simply preferred another route.

A valid certificate was necessary evidence, not a universal franchise

Modern infrastructure often treats certificates as inventories of names that can share operational machinery. That is useful, but it is easy to overread.

A certificate proves that the peer controls a private key associated with identities accepted by the client under its validation rules. It does not prove that every listed name enters the same tenant, port policy, application, backend pool or security boundary on every connection established with that certificate. Certificate breadth and serving configuration can overlap without being identical.

The distinction becomes clearer if three propositions are kept separate.

First, reachability: this channel reaches an endpoint. Second, credential coverage: the endpoint authenticated with evidence acceptable for the target origin. Third, connection-context acceptance: the receiving deployment is configured and willing to produce that origin's authoritative response on this particular channel.

The first two are strong enough to make reuse more than guesswork. They are not strong enough to seize the third decision from the server. Status 421 is the server's bounded veto over that final proposition.

This is not hostility to optimisation. It is what makes an optimistic optimisation governable. A client can act on the evidence available to it without pretending that its inference is irreversible.

Retry preserved the request and changed the context

The recovery rule is unusually explicit. A client receiving 421 may retry the request over a different connection, including a fresh connection dedicated to the target origin or a connection to an appropriate alternative service. The permission applies whether or not the method is idempotent.

That last clause should not be generalised. HTTP is not declaring every failed non-idempotent request safe to replay. It is describing a typed refusal in which the responding server has declined to produce the target origin's authoritative response in this context. The status gives the client grounds to treat a different connection as a correction of routing context rather than a repetition after an unknown application result.

Even then, MAY leaves the client discretion. Local policy may refuse replay. Credentials may be bound to a connection. The request body might not be reproducible. An application may demand confirmation before repeating a consequential operation. The protocol permits recovery; it does not compel risk.

What it does require conceptually is a changed condition. Sending the same request again over the same coalesced connection, with no new evidence and no limit, would turn a recovery mechanism into a loop. The target URI remains stable. The connection choice changes.

A fresh connection can matter even when it eventually reaches the same address and presents the same certificate. Its handshake can carry the target origin's SNI, select a different service context and establish a narrower operational route.

421 was not a redirect in disguise

Redirects ask the client to consider another target. They normally carry a location whose URI changes the next request's destination or identification. A 421 response does neither.

The client is not told that the content lives elsewhere. It is told that this server context cannot or will not authoritatively answer the URI already named. Recovery tries to deliver the same meaning through a different connection.

That difference protects accountability. If an operator responds to a routing mismatch with a redirect, it may expose an internal hostname, transfer credentials to another authority, change cache keys or conceal that the original deployment's origin map is inconsistent. If a client interprets 421 as permission to change the URI, it delegates semantic choice to a response that never made such a claim.

Nor is 421 equivalent to 400 Bad Request. The request can be syntactically correct. It is not 403 Forbidden, because the main fact is not a user's lack of permission to the resource. And it is not a TLS alert: TLS may have succeeded exactly as designed.

The value of a narrow status is that it prevents one layer's error vocabulary from acquiring authority over another layer's meaning.

ORIGIN moved part of the conversation before the mistake

Reactive correction costs time. The client sends a request, receives 421, opens or selects another connection and tries again. RFC 8336, published in March 2018, introduced an HTTP/2 ORIGIN frame so servers could give clients prospective information about which origins a connection might be used for.

The extension defines an Origin Set for a connection. Once that set has been initialized, a supporting client must not consider the connection authoritative for an origin absent from it. Entries are explicit origins; wildcard names are not allowed. A wildcard certificate therefore does not silently become an unlimited ORIGIN advertisement.

The signal is hop by hop because it describes one connection. Intermediaries do not forward it, and clients configured to use a proxy ignore it from that proxy. The server can incrementally add origins through later frames, but certificate validation remains required. ORIGIN is not a replacement credential and does not grant a name merely because the server listed it.

RFC 8336 also closes the feedback loop. When a supporting client receives 421, it removes the corresponding origin from that connection's Origin Set. The negative response is no longer an isolated error page. It updates the client's model of where future requests for that origin should not go.

The most precise memory key is origin plus connection. Removing the origin globally would overlearn from a local mismatch. Forgetting the response immediately would repeat the same failed inference.

Alt-Svc nominated an endpoint without erasing authority checks

An origin can advertise an alternative service, allowing clients to use another host, port or protocol endpoint for the same origin. That creates another route-selection opportunity, but the advertisement does not by itself rewrite the authority model.

RFC 8336 states that Alt-Svc advertisements do not modify the Origin Set. RFC 9110's 421 recovery may choose an alternative service, yet the selected connection still needs the evidence and configuration appropriate to the target origin.

This prevents a chain of convenient signals from becoming circular proof. A certificate can support authentication. DNS can support reachability. Alt-Svc can nominate an alternative. ORIGIN can state a connection's intended origin set. None of them alone proves every other proposition, and 421 remains available when the receiving context rejects the combination.

Thin signals cooperate because their claims stay bounded.

HTTP/3 changed the transport and kept the veto

The current HTTP/2 specification, RFC 9113, retains cross-origin connection reuse and 421 while replacing RFC 7540. HTTP/3, RFC 9114, carries the same boundary into QUIC.

HTTP/3 no longer rides on TCP, but its connections are still persistent and may be reused for different URI authorities. Before using an existing connection for a new origin, the client must validate the certificate for that origin. If the certificate is unacceptable, reuse is forbidden. Even after acceptable validation, a server that does not wish the HTTP/3 connection to be reused for a particular origin can return 421.

The survival is revealing. The status was born in HTTP/2, yet its meaning was later placed in general HTTP semantics and used by HTTP/3. The underlying problem is not a particular binary frame or TCP's connection machinery. It appears whenever performance allows several named authorities to share one channel while the receiving deployment retains context that the sender cannot fully observe.

Efficiency created the inference. Distributed authority required an escape from it.

The right observability follows the failed edge

A 421 counter without connection context says little. Operators need to know which target origin was carried over which channel, why that channel was selected and what changed on retry.

Useful evidence includes scheme, host and port; request method; connection identifier; negotiated HTTP version; remote endpoint; SNI; ALPN; certificate identity set; DNS evidence used for reuse; Alt-Svc provenance; advertised Origin Set; selected frontend and backend; the role that emitted 421; and the new connection identifier, if any.

The comparison between paths is especially valuable. If a fresh origin-specific connection succeeds while the coalesced one returns 421, connection-context selection becomes the leading explanation. If both return 421, the origin may be absent or misconfigured more broadly. If only one deployment region fails, shared certificates or advertisements may have outrun backend convergence.

The status should be rare enough to investigate but ordinary enough not to panic over. It can be a healthy correction of an optimistic attempt. Repetition without convergence is the warning.

A negative answer protected plural control

Connection coalescing concentrates work because concentration is efficient. It reduces handshakes and allows one scheduler and congestion context to carry several streams. That gain does not require the first connection to become sovereign over every origin its certificate can name.

The client controls its reuse decision. The certificate authority and validation policy shape acceptable identity evidence. DNS and alternative-service records shape endpoint selection. A TLS terminator can select a service context. The origin operator controls the map from authority and connection context to an application prepared to answer. Each layer contributes evidence without receiving a universal mandate.

421 is small enough to preserve that distribution. It does not design the backend. It does not appoint a new origin. It gives the party holding the missing configuration fact a precise way to reject one attempted edge, while leaving the request's identity intact.

The Internet often becomes safer not by eliminating inference, but by making inference reversible at the boundary where better evidence exists.

The connection was real; its mandate was not

The tempting mistake is to equate successful establishment with complete authority. A socket exists, so every name on the certificate must belong on it. A multiplexed channel is efficient, so every service it can reach must accept its inherited context. A client checked all visible preconditions, so the server must honour the result.

HTTP 421 rejects that escalation.

The connection remains real. It can continue serving the origin for which it is appropriate. The second origin remains real too. A fresh connection may reach it successfully. What failed was the proposition joining that origin to that connection at that moment.

The current IANA HTTP Status Code Registry records 421 as Misdirected Request and points to RFC 9110. Registration fixes the interoperable name and reference; it does not prove how often the status appears, that every client retries, or that any particular deployment has configured its origin boundaries correctly.

By naming the failed edge instead of condemning either endpoint, HTTP kept performance subordinate to authority. One channel could carry many streams without turning shared transport into shared rule.