Codici di stato 2xx di successo

Cosa copre la famiglia 2xx

Il successo non è una singola condizione. Un browser che recupera una pagina, un modulo che pubblica un nuovo record, un job in background che accetta un lavoro per dopo e un lettore video che chiede i byte da 5.000.000 a 6.000.000 hanno tutti successo, ma hanno bisogno di risposte diverse. È questo che codificano i codici 2xx. L'RFC 9110 definisce da 200 a 206; una manciata di altri viene da estensioni come WebDAV.

Per il traffico web quotidiano, la stragrande maggioranza delle risposte di successo sono semplici 200. Il resto conta soprattutto per i client API, i percorsi di upload e la consegna di contenuti multimediali.

I codici 2xx e quando compare ciascuno

• 200 OK. Il successo standard. Per una GET il corpo è la risorsa richiesta; per una POST è il risultato dell'azione. È ciò che restituisce una pagina sana.
• 201 Created. La richiesta ha creato una nuova risorsa. Un'API ben progettata restituisce 201 con un'intestazione Location che punta alla cosa appena creata. Lo vedi nei log delle API, raramente in un browser.
• 202 Accepted. La richiesta è stata accettata per l'elaborazione ma non è finita. Usato per lavori asincroni come un'importazione in massa o un report che verrà generato in background. Un 202 è una promessa, non un risultato, quindi il client normalmente deve interrogare un URL di stato.
• 203 Non-Authoritative Information. Successo, ma un proxy o un intermediario di trasformazione ha modificato la risposta lungo il percorso. Non comune sui siti moderni.
• 204 No Content. Successo con deliberatamente nessun corpo. Tipico per una DELETE, una PUT che ha salvato senza bisogno di rimandare nulla indietro, o un endpoint di salvataggio automatico. Il browser resta sulla pagina attuale.
• 205 Reset Content. Successo, e il client dovrebbe ripristinare il modulo o la vista del documento che ha inviato la richiesta. Raramente usato nella pratica.
• 206 Partial Content. Il server sta restituendo solo l'intervallo di byte che il client ha chiesto con un'intestazione Range. È così che funzionano la ricerca nel video, i download ripristinabili e i trasferimenti di file grandi, quindi 206 è normale e atteso sugli endpoint multimediali.
• 207 Multi-Status e 208 Already Reported vengono da WebDAV, dove una richiesta può agire su molte risorse e ha bisogno di riportare un esito per singola risorsa. 226 IM Used viene dall'estensione di codifica delta ed è distribuito molto raramente.

Perché un 200 non prova che la pagina sia sana

Un codice di stato descrive l'esito della transazione HTTP, non la correttezza di ciò che è tornato indietro. Una pagina brandizzata "siamo offline per manutenzione" viene servita con un 200. Così anche una pagina di errore dell'applicazione, quando il framework cattura l'eccezione e renderizza delle scuse amichevoli tramite il template normale con il suo stato predefinito. Una pagina renderizzata lato client la cui chiamata API è fallita restituisce 200 per il guscio vuoto attorno al contenuto mancante, e un soft 404 restituisce 200 per un messaggio "pagina non trovata", il che confonde anche i motori di ricerca.

In ognuno di questi casi un controllo del codice di stato segnala successo mentre i tuoi visitatori vedono un sito rotto. La soluzione è un controllo di contenuto: fai un assert che una stringa nota sia presente nel corpo della risposta, o che una stringa di errore nota sia assente, oltre a controllare il codice.

Come verificare cosa restituisce davvero un URL

1. Chiedi solo le intestazioni e leggi la riga di stato:

   curl -sI https://example.com/ | head -n 1

2. Se è un 200, recupera anche il corpo e conferma che contenga quello che dovrebbe. Cerca con grep una stringa che compare solo su una pagina funzionante, come un titolo o un marcatore nel footer.
3. Per un endpoint API, verifica che il codice corrisponda alla semantica: una creazione dovrebbe essere 201 con una Location, un'eliminazione dovrebbe essere 204, e un job di lunga durata dovrebbe essere 202 con un URL di stato.
4. Per i contenuti multimediali, conferma che il server pubblicizzi Accept-Ranges: bytes e risponda a una richiesta con intervallo con 206. Se risponde 200 a una richiesta con intervallo, la ricerca sarà lenta perché l'intero file viene reinviato.
5. Ripeti il controllo da una rete diversa. Una risposta che è 200 per te e un errore altrove indica DNS, CDN o instradamento geografico invece dell'applicazione.

Controllare il corpo, non solo il codice

Un controllo del codice di stato segnalerà come sano un sito che sta servendo una pagina di errore, quindi abbinalo a un'asserzione di contenuto sulla stessa richiesta. HostTracker monitora siti web dal 2004 e offre 13 tipi di monitor, così un URL può essere osservato per il suo codice di stato, per una parola chiave nella risposta e per il tempo di risposta contemporaneamente. Fai passare un URL attraverso lo strumento di controllo HTTP per vedere il codice e le intestazioni che restituisce in questo momento, poi leggi cosa significa davvero un 200 OK e i codici di errore server 5xx per i fallimenti che un 200 può mascherare.