General interview: How do you diagnose and safely retry HTTP 421 Misdirected Request?
Prompt and context
A client using HTTP/2 connection reuse intermittently receives 421 Misdirected Request while calling several HTTPS domains. Explain what the response means, how to separate protocol routing from application errors, how to inspect SNI, authority, and the proxy chain, and how to retry safely.
What the interviewer evaluates
- Understanding 421 as a server unable to serve the requested scheme and authority on the current path.
- Connecting TLS SNI, certificates, HTTP/2 connection reuse, and reverse-proxy routing.
- Tracing the request across the client, edge, proxy, and origin.
- Retrying on a new connection without duplicating side effects.
Questions to clarify before answering
- Does 421 occur on HTTP/1.1, HTTP/2, or HTTP/3, and only on reused connections?
- Do scheme, authority, Host, SNI, and certificate SAN agree?
- Do DNS, a load balancer, CDN, or service mesh send multiple domains to one connection?
- Does a proxy rewrite Host, authority, or TLS termination details?
- Is the request idempotent, protected by an idempotency key, and within a retry deadline?
30-second answer framework
421 means the server believes the request was sent to the wrong connection or node, not that a normal business validation failed. I record authority, SNI, certificate, connection ID, and proxy hops, then compare successful and failing paths. If reuse or routing mismatch is confirmed, the client may retry on a new connection, automatically only for idempotent or idempotency-keyed requests and with a cap. The fix is usually connection-pool grouping, SNI/Host preservation, or proxy routing rather than more blind retries.
Step-by-step deep dive
Step 1: Define the 421 boundary
RFC 9110 defines 421 when the origin believes a request was misdirected and cannot produce a response for the URI's scheme and authority combination. It is different from a missing resource, denied permission, or business validation error.
Step 2: Verify the target identity
Capture URL scheme, authority, Host, SNI, certificate SAN, ALPN, and connection-reuse markers. An HTTPS request needs a certificate and TLS identity covering the target origin; DNS resolution alone is not enough.
Step 3: Inspect pooling and reuse
HTTP/2 can carry many requests on one connection, but a server may reject an authority on an already established connection. Check whether pools are grouped by proxy, TLS parameters, and authority, and whether an old connection is reused incorrectly.
Step 4: Trace the proxy chain
Record request ID, authority, SNI, selected upstream, and status at the CDN, gateway, service mesh, and origin. Compare the nodes visited by successful and 421 requests to find Host rewriting, missing SNI, or bad routing.
Step 5: Retry on a new connection
The specification permits a client to retry a 421 on a different connection. The new connection must redo DNS, TLS, ALPN, and authority binding; sending the same request on the old connection is not enough. Check method idempotency, replayable body, and deadline first.
Step 6: Fix server-side routing
Keep scheme, authority, SNI, and certificate configuration aligned at the edge and origin, and preserve required fields while forwarding. For wildcard or shared certificates, explicitly decide which domains may share connections and which must be isolated.
Step 7: Add observability and regression tests
Measure 421 by authority, connection ID, protocol, node, and certificate version. Use multi-domain HTTP/2 load tests, reuse toggles, and fault injection to validate the fix and ensure new-connection retries do not hide a persistent routing defect.
High-quality sample answer
I would first check whether 421 appears only on reused HTTP/2 connections. Logs capture scheme, authority, Host, SNI, certificate SAN, ALPN, connection ID, and proxy upstream. If a failed api.example.com request was reused on a connection configured only for static.example.com, that matches 421. The client retries once on a new connection only for GET or an idempotency-keyed request; a write goes to the business layer for confirmation. The server checks that CDN, gateway, and origin preserve authority and SNI and groups pools by domain. I then measure 421 by domain and node and validate the fix with multi-domain reuse tests.
Common mistakes
- Treating 421 as 404, 401, or ordinary 400 and changing business parameters.
- Checking DNS but not SNI, certificate SAN, authority, or proxy forwarding.
- Retrying forever on the same connection after 421.
- Automatically replaying a side-effecting POST without idempotency protection.
- Keeping only the final client error and losing per-hop connection and routing evidence.
Follow-ups and responses
Follow-up 1: What is the key difference between 421 and 400?
400 usually indicates invalid request syntax or message framing. 421 points to a mismatch between the target and the current server or connection, especially routing, authority, or TLS identity.
Follow-up 2: Why does HTTP/2 expose this more often?
HTTP/2 supports multiplexing and shared connections, so a client can send multiple authorities over one TLS connection. A server that rejects that combination returns 421.
Follow-up 3: Will changing the IP fix it?
Not necessarily. If pooling, SNI, or proxy rewriting is wrong, a different IP only changes the probability. Verify the new connection's TLS identity and complete route first.
Follow-up 4: When can POST be retried?
Only when the API has an idempotency key, server deduplication, or an explicit replay contract, and the body remains available within the deadline.
Follow-up 5: How do you prove connection reuse is causal?
Compare reuse enabled and disabled, connection IDs, authority sequences, and failing nodes. A successful fresh connection plus reproducible reuse failures provides stronger evidence.
Follow-up 6: What should production alert on?
Monitor 421 rate, retry success, and new-connection creation by authority, protocol, edge node, and certificate version. A spike often signals routing or certificate drift.