Kody statusu sukcesu 2xx

Co obejmuje rodzina 2xx

Sukces to nie jeden warunek. Przeglądarka pobierająca stronę, formularz wysyłający nowy rekord, zadanie w tle przyjmujące pracę do wykonania później i odtwarzacz wideo proszący o bajty od 5 000 000 do 6 000 000 - wszystkie są sukcesem, ale potrzebują różnych odpowiedzi. To właśnie kodują kody 2xx. RFC 9110 definiuje 200 do 206; garstka innych pochodzi z rozszerzeń, takich jak WebDAV.

Dla codziennego ruchu webowego przytłaczająca większość udanych odpowiedzi to zwykłe 200. Reszta ma znaczenie głównie dla klientów API, ścieżek przesyłania plików i dostarczania mediów.

Kody 2xx i kiedy każdy się pojawia

• 200 OK. Standardowy sukces. Dla GET treścią jest żądany zasób; dla POST jest to wynik akcji. To właśnie zwraca zdrowa strona.
• 201 Created. Żądanie utworzyło nowy zasób. Dobrze zbudowane API zwraca 201 z nagłówkiem Location wskazującym na właśnie utworzoną rzecz. Widuje się to w logach API, rzadko w przeglądarce.
• 202 Accepted. Żądanie zostało przyjęte do przetworzenia, ale nie jest jeszcze zakończone. Używane dla pracy asynchronicznej, takiej jak zbiorczy import albo raport, który zostanie wygenerowany w tle. 202 to obietnica, a nie wynik, więc klient zwykle musi odpytywać URL statusu.
• 203 Non-Authoritative Information. Sukces, ale proxy albo pośrednik przekształcający zmodyfikował odpowiedź po drodze. Rzadkie na nowoczesnych witrynach.
• 204 No Content. Sukces celowo bez treści. Typowy dla DELETE, dla PUT, które zapisało bez potrzeby odesłania czegokolwiek z powrotem, albo dla endpointu autozapisu. Przeglądarka pozostaje na bieżącej stronie.
• 205 Reset Content. Sukces, a klient powinien zresetować formularz albo widok dokumentu, który wysłał żądanie. W praktyce rzadko używane.
• 206 Partial Content. Serwer zwraca tylko zakres bajtów, o który poprosił klient nagłówkiem Range. Tak działa przewijanie wideo, wznawialne pobieranie i transfer dużych plików, więc 206 jest normalne i oczekiwane na endpointach medialnych.
• 207 Multi-Status i 208 Already Reported pochodzą z WebDAV, gdzie jedno żądanie może działać na wielu zasobach i musi zgłosić wynik dla każdego z osobna. 226 IM Used pochodzi z rozszerzenia kodowania różnicowego i jest wdrażane bardzo rzadko.

Dlaczego 200 nie dowodzi, że strona jest zdrowa

Kod statusu opisuje wynik transakcji HTTP, a nie poprawność tego, co wróciło. Firmowana strona "jesteśmy w trakcie prac serwisowych" jest serwowana z kodem 200. Tak samo strona błędu aplikacji, gdy framework przechwytuje wyjątek i renderuje uprzejme przeprosiny przez zwykły szablon z domyślnym statusem. Strona renderowana po stronie klienta, której wywołanie API zawiodło, zwraca 200 dla pustej powłoki wokół brakującej treści, a miękki 404 zwraca 200 dla komunikatu "strony nie znaleziono", co też myli wyszukiwarki.

W każdym z tych przypadków sprawdzenie kodu statusu zgłasza sukces, podczas gdy Twoi odwiedzający widzą zepsutą witrynę. Naprawą jest sprawdzenie treści: potwierdź, że w treści odpowiedzi jest obecny znany ciąg znaków, albo że nieobecny jest znany ciąg błędu, oprócz sprawdzania samego kodu.

Jak sprawdzić, co naprawdę zwraca URL

1. Poproś tylko o nagłówki i przeczytaj linię statusu:

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

2. Jeśli to 200, pobierz też treść i potwierdź, że zawiera to, co powinna. Wyszukaj ciąg, który pojawia się tylko na działającej stronie, na przykład nagłówek albo znacznik stopki.
3. Dla endpointu API zweryfikuj, czy kod pasuje do semantyki: utworzenie powinno dać 201 z Location, usunięcie powinno dać 204, a długo trwające zadanie powinno dać 202 z URL statusu.
4. Dla mediów potwierdź, że serwer ogłasza Accept-Ranges: bytes i odpowiada na żądanie z zakresem kodem 206. Jeśli odpowiada 200 na żądanie z zakresem, przewijanie będzie wolne, bo cały plik jest wysyłany ponownie.
5. Powtórz sprawdzenie z innej sieci. Odpowiedź, która jest 200 u Ciebie, a błędem gdzie indziej, wskazuje na DNS, CDN albo trasowanie geograficzne, a nie na aplikację.

Sprawdzanie treści, nie tylko kodu

Sprawdzenie kodu statusu zgłosi zieloną witrynę, która serwuje stronę błędu, więc połącz je z asercją treści na tym samym żądaniu. HostTracker monitoruje witryny od 2004 roku i oferuje 13 typów monitorów, więc jeden URL może być jednocześnie obserwowany pod kątem kodu statusu, słowa kluczowego w odpowiedzi i czasu odpowiedzi. Przepuść URL przez narzędzie sprawdzenia HTTP, żeby zobaczyć kod i nagłówki, które zwraca właśnie teraz, a potem przeczytaj co naprawdę oznacza 200 OK oraz kody błędów serwera 5xx, żeby poznać awarie, które 200 może maskować.