200 OK: co oznacza i co ukrywa
200 OK oznacza, że serwer odebrał żądanie, zrozumiał je i zwrócił udaną odpowiedź, ale nic nie mówi o tym, czy treść w tej odpowiedzi jest poprawna. Komunikat o konserwacji, strona błędu i pusty szablon mogą być serwowane z kodem 200 tak samo.
Co gwarantuje 200
200 to standardowy status sukcesu. Mówi o wąskim i konkretnym zestawie rzeczy: DNS się rozwiązał, nawiązano połączenie TCP, TLS się wynegocjował, jeśli URL był HTTPS, serwer zaakceptował linię żądania i nagłówki, i wyprodukował odpowiedź, którą uważa za udaną. Dla GET treść to żądany zasób; dla POST to wynik akcji.
Czego 200 Ci nie mówi, to czy strona zawiera katalog produktów, czy formularz płatności się wyrenderował, czy JavaScript wypełniający stronę otrzymał swoje dane, ani czy odpowiedź, którą dostałeś, to ta sama, którą dostają Twoi odwiedzający z innego kraju. To wszystko żyje w treści, a kod statusu nigdy nie zagląda do treści.
200, które w rzeczywistości jest awarią
Sam monitoring kodu statusu nie wystarcza, bo zepsuta strona odpowiada 200 we wszystkich tych przypadkach:
- Strona konserwacji. Celowo serwowana z kodem 200 przez skrypt wdrożeniowy albo regułę CDN. Uptime wygląda idealnie przez całe okno awarii.
- Złapany wyjątek aplikacji. Framework przechwytuje błąd i renderuje przyjazną stronę "coś poszło nie tak" przez normalny potok szablonów, który ustawia domyślny status 200.
- Miękkie 404. Komunikat "strony nie znaleziono" zwrócony z kodem 200 zamiast 404. Odwiedzający są zdezorientowani, a wyszukiwarki mogą wciąż trzymać URL w indeksie albo uznać cały wzorzec za niskiej jakości.
- Pusta powłoka renderowana po stronie klienta. Dokument HTML ładuje się bez problemu, ale wywołanie API, które ma go wypełnić, zawiodło. Status to 200, a strona jest pusta.
- Nieaktualna albo w złym języku zbuforowana kopia. Węzeł brzegowy, którego pobranie od serwera źródłowego zawiodło, dalej serwuje to, co już ma, z kodem 200.
- Zaparkowana albo przejęta domena. Po zmianie DNS odpowiada 200 z czyjąś inną treścią.
Wolne 200 to wciąż problem
Czas odpowiedzi często liczy się bardziej niż kod. Strona, która zwraca 200 po dwunastu sekundach, jest funkcjonalnie niedostępna dla większości odwiedzających, którzy zdążą wyjść, zanim się załaduje. Kod statusu w ogóle nie ma wymiaru czasowego, więc musisz mierzyć czas odpowiedzi i ustawiać dla niego osobny próg. Z tego samego powodu warto obserwować rozmiar: 200, które zwraca 300 bajtów tam, gdzie normalnie zwraca 80 KB, to silny sygnał, że strona wyrenderowała się bez swojej treści.
Jak zweryfikować, że 200 to prawdziwy sukces
- Czytaj linię statusu i czas razem:
curl -sI -o /dev/null -w "%{http_code} in %{time_total}s\n" https://example.com/ - Pobierz treść i asertuj na ciągu znaków, który pojawia się tylko wtedy, gdy strona naprawdę działa, na przykład nagłówek, cena czy znacznik stopki, a nie na czymś, co zawiera też szablon błędu.
- Asertuj zarówno na obecności, jak i braku. Wyszukiwanie fraz takich jak "trwa konserwacja", "chwilowo niedostępne" czy treść wyjątku Twojego frameworka wyłapuje przypadek przyjaznego błędu.
- Porównaj rozmiar odpowiedzi z znanym dobrym punktem odniesienia. Nagłe zapadnięcie się długości treści zwykle oznacza, że wyrenderowała się powłoka, a treść nie.
- Sprawdzaj głęboką stronę, nie tylko stronę główną. Strony główne są najmocniej buforowane i najbardziej skłonne wciąż odpowiadać 200, podczas gdy aplikacja za nimi jest zepsuta.
- Powtarzaj z więcej niż jednej sieci. 200 z Twojego biura i błąd z innego kontynentu wskazuje na DNS, CDN albo routing geograficzny, a nie na samą aplikację.
Co może przeoczyć zielona kontrola uptime
Monitor, który czyta tylko kod statusu, będzie raportować zieloną stronę przez cały incydent, który zaczął się od strony konserwacji, której nikt nie usunął. Połączenie kontroli statusu z asercją słów kluczowych i progiem czasu odpowiedzi to właśnie to, co zamienia "serwer odpowiedział" w "strona działała". HostTracker oferuje 13 typów monitorów i alertuje e-mailem, SMS-em, telefonicznie, przez Slack, Telegram i więcej, więc niezgodność treści wywołuje ten sam alert co awaria. Przepuść adres URL przez narzędzie do kontroli HTTP, żeby zobaczyć jego status, nagłówki i czas, albo przeczytaj o rodzinie 2xx i 500 Internal Server Error, czyli odpowiedziach, które ukrywa przyjazna strona błędu.