Oczywiście, że serwer rozróżnia błędy po stronie klienta od błędów po stronie serwera. Jest to fundamentalna zasada komunikacji w sieci, a mechanizmem, który na to pozwala, są Kody Statusu HTTP (ang. HTTP Status Codes). To właśnie te trzycyfrowe numery, które serwer wysyła w odpowiedzi na każde żądanie klienta (np. przeglądarki internetowej), stanowią precyzyjny język informujący o rezultacie operacji, w tym o charakterze ewentualnego błędu.

Kody statusu HTTP: Język komunikacji serwer-klient

Kody statusu HTTP są podzielone na pięć klas, z których każda jest sygnalizowana przez pierwszą cyfrę kodu. Ta klasyfikacja pozwala natychmiast określić ogólny charakter odpowiedzi, a co najważniejsze – rozróżnić, czy problem leży po stronie klienta, czy serwera.

Pięć głównych klas kodów statusu HTTP:

1. 1xx (Informacyjne): Żądanie zostało odebrane i przetwarzanie jest kontynuowane.
2. 2xx (Powodzenie): Żądanie zostało pomyślnie odebrane, zrozumiane i przetworzone przez serwer (np. 200 OK).
3. 3xx (Przekierowanie): Wymagane jest podjęcie dalszych działań w celu zakończenia żądania (np. 301 Moved Permanently).
4. 4xx (Błąd klienta): Serwer uważa, że błąd leży po stronie klienta, co uniemożliwia spełnienie żądania.
5. 5xx (Błąd serwera): Żądanie zostało zaakceptowane, ale błąd po stronie serwera uniemożliwił jego spełnienie.

Kluczowe dla odpowiedzi na Twoje pytanie są właśnie klasy 4xx i 5xx.

Błędy po stronie klienta (Kody 4xx)

Kody z grupy 4xx sygnalizują, że serwer nie może lub nie chce przetworzyć żądania z powodu błędu, który według serwera leży po stronie klienta. Oznacza to, że to klient (np. przeglądarka, aplikacja mobilna, bot wyszukiwarki) wysłał nieprawidłowo sformułowane żądanie, żąda dostępu do nieistniejącego zasobu lub nie ma do niego odpowiednich uprawnień.

Przykłady popularnych błędów 4xx:

• 400 Bad Request: Serwer nie może zrozumieć żądania z powodu nieprawidłowej składni, np. uszkodzonych plików cookie, nieprawidłowych nagłówków HTTP lub zbyt długiego adresu URL.
• 401 Unauthorized: Żądanie nie zostało zastosowane, ponieważ brakuje w nim ważnych danych uwierzytelniających (klient musi się uwierzytelnić).
• 403 Forbidden: Serwer zna tożsamość klienta, ale odmawia dostępu do zasobu, ponieważ klient nie ma do niego uprawnień.
• 404 Not Found: Najbardziej znany błąd. Serwer nie może znaleźć żądanego zasobu (URL nie jest rozpoznawany).
• 405 Method Not Allowed: Żądana metoda HTTP (np. DELETE lub POST) jest znana serwerowi, ale nie jest obsługiwana dla danego zasobu.
• 429 Too Many Requests: Klient wysłał zbyt wiele żądań w określonym czasie (mechanizm ograniczania szybkości, tzw. rate-limiting).

Wnioski dla serwera: Serwer, zwracając kod 4xx, informuje klienta: "Twoje żądanie jest niepoprawne i to Ty musisz je poprawić, zanim spróbujesz ponownie."

Błędy po stronie serwera (Kody 5xx)

Kody z grupy 5xx wskazują, że żądanie klienta było prawidłowe, ale serwer napotkał wewnętrzny błąd, który uniemożliwił jego spełnienie. Oznacza to, że problem leży w logice aplikacji serwerowej, konfiguracji, przeciążeniu zasobów lub komunikacji z innymi usługami (np. bazą danych).

Przykłady popularnych błędów 5xx:

• 500 Internal Server Error: Ogólny, niesprecyzowany błąd serwera. Jest to najczęściej spotykany błąd, który sygnalizuje, że serwer napotkał nieoczekiwany problem, np. błąd w kodzie aplikacji.
• 502 Bad Gateway: Serwer, działając jako brama lub proxy, otrzymał nieprawidłową odpowiedź od serwera nadrzędnego (np. serwera bazy danych lub innej usługi).
• 503 Service Unavailable: Serwer jest tymczasowo niedostępny, często z powodu przeciążenia, konserwacji lub wyczerpania zasobów (RAM, CPU).
• 504 Gateway Timeout: Serwer, działający jako brama, nie otrzymał na czas odpowiedzi od serwera nadrzędnego.

Wnioski dla serwera: Serwer, zwracając kod 5xx, informuje klienta: "Twoje żądanie jest w porządku, ale ja nie jestem w stanie go przetworzyć. Spróbuj później, a w międzyczasie administrator musi naprawić mój błąd wewnętrzny."

Jak serwer "wie", z jakim błędem ma do czynienia?

Serwer nie "zgaduje", skąd pochodzi błąd. Cały proces jest zautomatyzowany i zależy od logicznego przepływu przetwarzania żądania:

1. Weryfikacja żądania klienta (4xx): Serwer najpierw analizuje samo żądanie HTTP. Sprawdza jego poprawność składniową (czy jest zgodne ze specyfikacją HTTP), czy klient ma uprawnienia do zasobu (autoryzacja), czy żądany zasób istnieje, i czy użyta metoda jest dozwolona. Jeśli na tym etapie wykryje nieprawidłowość (np. niepoprawny format danych, brak nagłówka autoryzacyjnego, żądanie nieistniejącego pliku), natychmiast generuje odpowiedni kod z grupy 4xx i wysyła go z powrotem do klienta.
2. Przetwarzanie wewnętrzne (5xx): Jeśli żądanie klienta jest poprawne i serwer je zaakceptuje, rozpoczyna się wewnętrzne przetwarzanie, czyli uruchamianie skryptów aplikacji (np. PHP, Python, Java), komunikacja z bazą danych, przetwarzanie logiki biznesowej. Jeśli na tym etapie wystąpi błąd (np. błąd w kodzie, awaria bazy danych, przekroczenie limitu pamięci), serwer (lub jego komponent, np. interpreter języka) generuje błąd wewnętrzny, który jest następnie mapowany na odpowiedni kod z grupy 5xx.

W praktyce, serwer (lub aplikacja na nim działająca) jest zaprogramowany tak, aby świadomie wybrać odpowiedni kod statusu. Na przykład, jeśli klient próbuje uzyskać dostęp do pliku, który został usunięty, logika serwera zwróci 404. Jeśli natomiast kod PHP wywoła nieobsługiwany wyjątek (np. błąd połączenia z bazą danych), serwer zwróci 500.

To precyzyjne rozróżnienie jest kluczowe nie tylko dla programistów, którzy dzięki temu wiedzą, czy mają debugować kod po stronie front-endu (klienta) czy back-endu (serwera), ale także dla robotów wyszukiwarek (SEO), które na podstawie kodów 4xx i 5xx podejmują decyzje o indeksowaniu strony.