200 OK: cosa significa e cosa nasconde

Cosa garantisce un 200

Un 200 è lo stato di successo standard. Ti dice un insieme ristretto e specifico di cose: il DNS ha risolto, è stata stabilita una connessione TCP, il TLS è stato negoziato se l'URL era HTTPS, il server ha accettato la riga di richiesta e gli header, e ha prodotto una risposta che considera riuscita. Per una GET il corpo è la risorsa richiesta; per una POST è il risultato dell'azione.

Ciò che un 200 non ti dice è se la pagina contenga il catalogo prodotti, se il form di checkout si sia renderizzato, se il JavaScript che riempie la pagina abbia ricevuto i suoi dati, o se la risposta che hai ottenuto sia quella che stanno ottenendo i tuoi visitatori in un altro paese. Tutto questo vive nel corpo, e il codice di stato non guarda mai il corpo.

Il 200 che in realtà è un fallimento

Il monitoraggio del solo codice di stato non basta, perché un sito rotto risponde 200 in tutti questi casi:

• Una pagina di manutenzione. Servita deliberatamente a 200 da uno script di deploy o da una regola CDN. L'uptime sembra perfetto per tutta la finestra di interruzione.
• Un'eccezione applicativa intercettata. Il framework cattura l'errore e renderizza una pagina amichevole "qualcosa è andato storto" attraverso la normale pipeline di template, che imposta lo stato predefinito a 200.
• Un soft 404. Un messaggio "pagina non trovata" restituito a 200 invece che a 404. I visitatori sono confusi e i motori di ricerca possono continuare a tenere l'URL indicizzato o trattare l'intero pattern come di bassa qualità.
• Un guscio vuoto renderizzato lato client. Il documento HTML si carica bene, ma la chiamata API che lo riempie è fallita. Lo stato è 200 e la pagina è vuota.
• Una copia in cache obsoleta o nella lingua sbagliata. Un nodo edge il cui recupero dall'origine è fallito continua a servire ciò che già ha, a 200.
• Un dominio parcheggiato o dirottato. Dopo una modifica DNS risponde 200 con il contenuto di qualcun altro.

Un 200 lento è comunque un problema

Il tempo di risposta conta spesso più del codice. Una pagina che impiega dodici secondi per restituire 200 è funzionalmente giù per la maggior parte dei visitatori, che se ne saranno andati prima che finisca. Il codice di stato non ha alcuna dimensione temporale, quindi devi misurare il tempo di risposta e imporre una soglia separatamente. Vale la pena osservare anche la dimensione per lo stesso motivo: un 200 che restituisce 300 byte dove normalmente ne restituisce 80 KB è un forte segnale che la pagina si è renderizzata senza il suo contenuto.

Come verificare che un 200 sia un vero successo

1. Leggi insieme la riga di stato e la temporizzazione:

   curl -sI -o /dev/null -w "%{http_code} in %{time_total}s\n" https://example.com/

2. Recupera il corpo e asserisci su una stringa che compare solo quando la pagina funziona davvero, come un titolo, un prezzo o un elemento del footer, invece che su qualcosa che contiene anche il template di errore.
3. Asserisci sia sull'assenza sia sulla presenza. Cercare frasi come "in manutenzione", "temporaneamente non disponibile" o il testo dell'eccezione del tuo framework intercetta il caso dell'errore amichevole.
4. Confronta la dimensione della risposta con una baseline nota come buona. Un crollo improvviso della lunghezza del corpo di solito significa che il guscio si è renderizzato e il contenuto no.
5. Controlla una pagina profonda, non solo la homepage. Le homepage sono le più pesantemente in cache e le più probabili a continuare a rispondere 200 mentre l'applicazione dietro di esse è rotta.
6. Ripeti da più di una rete. Un 200 dal tuo ufficio e un errore da un altro continente indica DNS, CDN o instradamento geografico invece dell'applicazione stessa.

Cosa può perdersi un controllo di uptime verde

Un monitor che legge solo il codice di stato segnalerà un sito verde durante un intero incidente iniziato con una pagina di manutenzione che nessuno ha rimosso. Abbinare il controllo dello stato con un'asserzione su parole chiave e una soglia sul tempo di risposta è ciò che trasforma "il server ha risposto" in "la pagina ha funzionato". HostTracker offre 13 tipi di monitor e avvisa via email, SMS, chiamata vocale, Slack, Telegram e altro, così una discrepanza di contenuto fa scattare lo stesso avviso di un'interruzione. Passa un URL attraverso lo strumento di controllo HTTP per vedere il suo stato, gli header e la temporizzazione, oppure leggi la famiglia 2xx e 500 Internal Server Error per le risposte che una pagina di errore amichevole sta nascondendo.