Codici di stato informativi 1xx

Cos'è una risposta provvisoria

Ogni altra famiglia di stato conclude lo scambio. Un 200, un 404 o un 502 è la parola finale del server su quella richiesta. Un 1xx è diverso: il server invia la riga di stato e qualsiasi header, poi mantiene la connessione aperta e invia una seconda risposta più tardi. RFC 9110 richiede che i client siano in grado di leggere una o più risposte 1xx prima di quella finale, e permette a qualsiasi client che non comprende un particolare codice 1xx di ignorarlo.

La risposta provvisoria viene scartata una volta arrivata quella finale, quindi la maggior parte degli strumenti non la mostra mai. Il pannello di rete del tuo browser, il log di accesso del tuo web server e un controllo di monitoraggio riportano tutti lo stato finale. La risposta provvisoria ha fatto il suo lavoro a livello di trasporto ed è scomparsa.

I codici 1xx che potresti incontrare

• 100 Continue. Il client ha inviato gli header della richiesta con Expect: 100-continue e si è fermato prima di inviare un corpo grande. Un 100 significa "gli header vanno bene, invia il corpo". Se il server rifiuterebbe comunque la richiesta, può rispondere con un errore finale invece, e il client non spreca mai banda caricando il payload. Questo è l'unico codice 1xx che svolge un lavoro utile sui siti ordinari, di solito dietro grandi upload di file e client API come curl.
• 101 Switching Protocols. Il client ha chiesto di cambiare protocollo con un header Upgrade e il server ha accettato. Questo è l'esito normale e riuscito di un handshake WebSocket, quindi un 101 in un log è generalmente un buon segno, non un incidente.
• 102 Processing. Definito dalla specifica WebDAV per richieste di lunga durata, così il client sa che il server non si è bloccato. È raramente implementato al di fuori di WebDAV ed è improbabile che lo incontri su un sito web normale.
• 103 Early Hints. Il server invia header Link in anticipo, prima di aver finito di generare la pagina, così il browser può iniziare a precaricare fogli di stile, font o script mentre l'HTML è ancora in produzione. È una funzionalità di prestazioni, non un segnale di errore, e normalmente la attivi deliberatamente sulla CDN o sull'origine.

Perché un 1xx non è qualcosa da correggere

Un 1xx da solo non porta con sé alcuna colpa. Non esiste una pagina che "restituisce 100" o "restituisce 101" nel modo in cui una pagina può restituire 404. Se hai un problema e un 1xx è da qualche parte nello scambio, l'informazione interessante è sempre il codice di stato finale che l'ha seguito, oppure il fatto che non sia arrivata affatto alcuna risposta finale.

I veri modi di fallimento vicino a un 1xx si manifestano come un blocco o un errore finale piuttosto che come il 1xx stesso:

• Un vecchio proxy o load balancer che non inoltra le risposte provvisorie, così un client in attesa di 100 Continue si blocca finché non scatta il proprio timeout.
• Un upgrade WebSocket che non raggiunge mai un 101 perché un proxy davanti all'applicazione rimuove gli header Upgrade e Connection. La connessione allora ripiega o fallisce del tutto.
• Early hint emessi con link a risorse che non esistono più, il che spreca richieste senza rompere la pagina.

Come vedere di persona una risposta 1xx

1. Usa un client verboso. Il normale curl -I mostra solo gli header della risposta finale, quindi chiedi invece lo scambio completo:

   curl -v -H "Expect: 100-continue" --data-binary @big.bin https://example.com/upload

   Un server collaborativo risponde HTTP/1.1 100 Continue prima che il corpo venga inviato, e poi il 2xx o 4xx finale.
2. Per un percorso WebSocket, controlla che l'handshake raggiunga HTTP/1.1 101 Switching Protocols. Se non lo fa, guarda prima il livello del proxy: gli header di upgrade sono hop-by-hop, e diverse configurazioni comuni di reverse proxy li eliminano per impostazione predefinita.
3. Per gli early hint, richiedi la pagina e cerca un blocco 103 prima della risposta finale. Non tutti gli intermediari lo lasciano passare, quindi un 103 assente non significa sempre che l'origine non ne stia inviando uno.
4. Se un upload grande si blocca senza alcuna risposta, riprova senza l'header Expect. Se il nuovo tentativo riesce, qualcosa tra te e l'origine sta inghiottendo le risposte provvisorie.

Monitorare uno scambio che non puoi vedere

Poiché i codici 1xx non raggiungono mai un log o una dashboard, ciò che monitori è la risposta finale e quanto tempo ha impiegato ad arrivare. Un percorso di upload bloccato su una risposta provvisoria appare dall'esterno esattamente come un endpoint lento o in timeout, e un controllo esterno lo vede subito. HostTracker esegue controlli da oltre 300 postazioni in 158 città, così una richiesta che si blocca dietro un particolare percorso di rete è distinguibile da un'interruzione genuina. Passa un URL attraverso lo strumento di controllo HTTP per vedere lo stato finale e il tempo di risposta. Le guide codici di successo 2xx e codici di reindirizzamento 3xx coprono le risposte che concludono davvero uno scambio.