HTTP 421 Misdirected Request

Cos'e HTTP 421 Misdirected Request

Il codice HTTP 421 Misdirected Request, definito nella RFC 9110, indica che la richiesta e stata inviata a un server che non e configurato per produrre una risposta per la combinazione di schema e authority indicata. Tipico in scenari HTTP/2 con connection coalescing.

Connection coalescing HTTP/2

HTTP/2 permette ai browser di riusare la stessa connessione TLS per più hostname che risolvono allo stesso IP e condividono il certificato. E un'ottimizzazione che riduce handshakes ma ha un caso limite:

1. Browser apre connessione TLS a sito1.example.com (cert SAN: sito1, sito2).
2. Browser deve scaricare risorsa da sito2.example.com.
3. DNS conferma stesso IP, certificato copre entrambi: riusa connessione.
4. Browser invia richiesta con :authority: sito2.example.com.
5. Server vede SNI=sito1 ma authority=sito2: 421.

Perché il server emette 421

Il server emette 421 quando:

• L'hostname richiesto (Host o :authority) non e servito da quella istanza specifica.
• Configurazione virtual host non corrisponde alla connessione TLS stabilita.
• Sharding orizzontale dove diversi domini stanno su diversi backend.

Comportamento del client

Quando il client riceve 421 dovrebbe:

• Aprire una nuova connessione separata per quell'hostname.
• NON usare quella connessione coalesced per quell'hostname in futuro.
• Ritentare la richiesta.

I browser moderni (Chrome, Firefox) implementano questo fallback automaticamente. La maggior parte degli utenti non vede mai il 421.

Esempio

GET / HTTP/2
:authority: api.example.com
:scheme: https

HTTP/2 421 Misdirected Request
content-type: text/plain
connection: close

This connection cannot serve api.example.com. Use a separate connection.

SNI e certificati wildcard

Il problema sorge particolarmente con certificati wildcard (*.example.com) o multi-SAN. Il browser presume che il server gestisca tutti gli hostname coperti, ma il backend dietro il TLS terminator potrebbe non farlo. Configurazioni con Nginx come reverse proxy verso microservizi separati sono tipiche.

Configurazione Nginx per evitare 421

Per servire correttamente più hostname sullo stesso socket TLS:

server {
    listen 443 ssl http2;
    server_name sito1.example.com sito2.example.com api.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Tutti i 3 hostname gestiti su questo server block
}

Se vuoi forzare connessioni separate per ragioni di sicurezza, dichiara hostname diversi in server block diversi e fai si che il certificato non li copra tutti.

Risposta corretta: forzare 421

A volte vuoi esplicitamente rifiutare connection coalescing per evitare leaks tra hostname distinti:

server {
    listen 443 ssl http2;
    server_name sito-pubblico.com;
    # ...
}

server {
    listen 443 ssl http2;
    server_name sito-admin-interno.com;
    # configurazione restrittiva

    if ($host != "sito-admin-interno.com") {
        return 421;
    }
}

421 e HTTP/3

HTTP/3 (QUIC) ha analoghi meccanismi di connection migration. Il 421 mantiene la sua semantica: client dovra usare nuova connessione QUIC per quell'authority.

Differenza con altri 4xx

• 400 Bad Request: la richiesta e malformata.
• 404 Not Found: l'authority esiste ma la risorsa no.
• 421 Misdirected Request: l'authority non e servita su QUESTA connessione, ma esisterebbe su altra.

Quando NON serve fix lato server

Spesso il 421 e benigno: il client tornera con una nuova connessione, la richiesta verra servita. Se vedi rari 421 nei log, non e necessariamente un problema. Diventa importante se:

• Sono moltissimi (impatto performance).
• Client legacy non gestisce il fallback (loop di errori).
• Comportamento inatteso dell'utente (errori visibili in browser).

Diagnostica

curl --http2 -v https://api.example.com/

# Verifica i frame HTTP/2:
# < HEADERS, status 421
# < :status: 421

Strumenti come Wireshark e Chrome DevTools (Network -> protocol column) mostrano quando avviene connection coalescing e quando si verificano 421.

Edge cases

• Cloudflare e CDN simili gestiscono internamente il 421, tipicamente non lo vedi in produzione.
• HAProxy e altri load balancer L7 propagano correttamente authority/SNI se configurati con option http-pretend-keepalive o equivalenti.
• Self-signed certs con SAN limitate possono triggerare 421 più spesso in environment di test.

Connection coalescing in dettaglio

Chrome implementa connection coalescing aggressivamente per ottimizzare performance. Quando navighi su sito1.com che embede risorse di sito2.com, e i due risolvono allo stesso IP e condividono certificato, Chrome usa un'unica connessione TLS. Risparmio: zero handshake aggiuntivo, multiplexing HTTP/2 nativo.

421 e reverse proxy

Reverse proxy come Nginx davanti a backend separati per hostname diversi devono gestire bene il SNI: instradare in base a SNI a backend corretti. Se non lo fanno, generano 421 anche su connessioni legittime.

Mitigazioni in HAProxy

frontend https_front
    bind *:443 ssl crt /etc/ssl/example.com.pem
    use_backend sito1 if { ssl_fc_sni -i sito1.example.com }
    use_backend sito2 if { ssl_fc_sni -i sito2.example.com }

Browser fallback automatico

Chrome quando riceve 421 chiude la connessione coalesced e ne apre una nuova specifica per quel hostname. Il fallback e trasparente: l'utente non vede errori. Se il problema persiste (es. il nuovo TLS handshake fallisce), allora si scatena un vero errore di rete.

Test con curl

curl --resolve sito2.example.com:443:1.2.3.4 \
     --http2 \
     https://sito1.example.com -v

Forza curl a usare l'IP di sito1 per sito2, simulando coalescing. Se ottieni 421, il server non gestisce sito2 su quel binding.

Hai bisogno di aiuto?

Se il tuo sito mostra errori HTTP, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.