Kody odpowiedzi HTTP
W niektórych sytuacjach to, co wykrywa El Monito, nie pokrywa się z rzeczywistością.
Możliwe są, oczywiście, dwa przypadki: serwis zachowuje się poprawnie w przeglądarce, a El Monito pokazuje jego stan jako "Offline", lub na odwrót. Jeśli taka rozbieżność się utrzymuje, to należy ją potraktować jako bardzo cenną informację o trudnym do zauważenia błędzie: najprawdopodobniej serwis przesyła treści z niewłaściwym kodem HTTP.
Kody HTTP
Krótki opis, z pominięciem wielu nieistotnych teraz szczegółów: wymiana danych według protokołu HTTP odbywa się zawsze według wzoru "zapytanie-odpowiedź". Przeglądarka wysyła do serwera zapytanie zawierające adres zasobu (strony) i żądanie, co należy z nim zrobić (zwykle "pobrać" lub "zmienić"), a serwer odsyła odpowiedź z informacją o stanie wykonania polecenia oraz tekstem do wyświetlenia. Ta informacja o stanie jest przekazywana w postaci liczby -- kodu odpowiedzi HTTP. Najczęściej spotykane wartości to:
- 200: OK -- "wszystko w porządku, polecenie się powiodło, przesyłam tekst strony",
- 301: Trwale przeniesiony -- "tej strony już tu nie ma, ale przesyłam adres pod którym powinna teraz być, spróbuj tam",
- 404: Nie znaleziono -- "nie mam niczego z takim adresem, przesyłam wyjaśnienie",
- 500: Wewnętrzny błąd serwera -- "wiem o co chodzi, próbowałem wykonać polecenie, ale nie wyszło; przesyłam wyjaśnienie".
Specyfikacja HTTP wymienia więcej kodów, dla wygody pogrupowanych według pierwszej cyfry: kody 2xx to różne warianty odpowiedzi "OK, jest dobrze", 3xx to "przekierowanie, spróbuj inny adres", 4xx to "błąd po stronie klienta, np niewłaściwy adres lub źle sformułowane zapytanie", 5xx to "błąd po stronie serwera, np. problem ze skryptem, bazą danych, lub sprzętem."
Co z tego wynika w przypadku opisanych wcześniej rozbieżności? Po kolei:
"Mój serwis działa, a według El Monito jest w stanie Offline"
Najprawdopodobniej Twój serwis odsyła poprawną zawartość stron, ale z niewłaściwym kodem odpowiedzi, na przykład 404 lub 500 zamiast 200. Łatwo to sprawdzić w El Monito na stronie "historia" takiego serwisu poprzez wskazanie kursorem jednego z prostokątów z informacją o wynikach obserwacji:
To jest fragment zapisu obserwacji adresu http://elksoft.pl/nie-ma-takiej-strony. Każda stacja obserwacyjna przesyła, oprócz samego stanu (Online/Offline), także wyjaśnienie błędu, w tym przypadku -- 404.
Przeglądarki zwykle nie pokazują kodów odpowiedzi, więc z punktu widzenia użytkownika wszystko może wyglądać dobrze -- takie strony działają dokładnie tak samo jak z poprawnym kodem, działają odsyłacze, obrazki itp. Pomimo tego z punktu widzenia oprogramowania taki serwis nie działa. A to jest poważny problem z co najmniej dwóch powodów.
Po pierwsze, jeśli Google przeglądając zawartość serwisu trafi na takie strony, to je pominie, wychodząc z założenia że skoro serwis nie działa to cały ten tekst, który dostaje w odpowiedzi, zawiera tylko opis błędu, więc nie warto go indeksować.
Po drugie, przeglądarki i serwery proxy nie zapisują tekstów i obrazków otrzymanych z kodami oznaczającymi sytuacje błędne. Oznacza to wielokrotne ściąganie tych samych elementów stron, więc znacznie większe obciążenie serwera i połączenia z internetem.
"Mój serwis nie działa, a według El Monito jest Online"
Najprawdopodobniej mamy sytuację dokładnie odwrotną do poprzedniej. Na przykład: skrypt obsługujący serwis nie jest w stanie nawiązać połączenia z bazą danych i wyświetla opis błędu na stronie, ale przesyła odpowiedź z kodem 200, więc "jest OK".
Przeciwnie niż w poprzednim przypadku, Google i inne wyszukiwarki, polegając na kodzie odpowiedzi, potraktują ten opis błędu jak zamierzoną zawartość strony. W efekcie Twój serwis może zostać przez nie zapamiętany z niewłaściwą zawartością, aż do następnego pełnego przejrzenia zawartości.
Przeglądarki i serwery proxy, także na podstawie kodu, zapamiętają tekst z opisem błędu zamiast zawartości strony lub obrazka, co oznacza że poprawna treść może być dla części użytkowników niedostępna przez pewien czas po naprawieniu błędu.
Co z tym zrobić?
Przede wszystkim -- sprawdzić. Najprościej przy pomocy programu wget (dostępne są wersje na wszystkie popularne systemy operacyjne):
Parametr --server-response oznacza, że interesuje mnie nagłówek odpowiedzi. Zawartość nagłówka można tu rozpoznać po tym, że jest wcięta. Najbardziej interesująca jest pierwsza linia: "HTTP/1.1 404 Not Found" oznacza, że odpowiedź została przesłana według protokołu HTTP w wersji 1.1, kod odpowiedzi to 404, a krótki opis: "Not Found", czyli "nie znaleziono". Tak wygląda poprawna odpowiedź serwera na nierozpoznany adres.
Kolejny przykład:
To wygląda ciekawiej, bo po wysłaniu zapytania o adres "http://www.elksoft.pl/" wget otrzymał odpowiedź z kodem 301 ("Moved Permanently" -- "przeniesione na stałe") i adresem "http://elksoft.pl/". Prawidłową reakcją na 301 jest wysłanie kolejnego zapytania, ze wskazanym przez serwer adresem, i dokładnie to wget zrobił. Po drugim zapytaniu otrzymał odpowiedź ze statusem 200 ("OK").
Ogólnie, rezultat testów powinien być taki: kiedy w przeglądarce Twój serwis wygląda i zachowuje się poprawnie, to wywołania wget z tymi samymi adresami powinny kończyć się informacjami o statusie 2xx. Kiedy przeciwnie, serwis wyświetla informacje o błędach, wget powinien otrzymać właściwy kod z serii 4xx lub 5xx. Takie zachowanie w dużym stopniu wspierają wszelkie serwery WWW i serwery aplikacyjne -- w razie wykrycia błędów, wyjątków lub innego zatrzymania skryptu w niewłaściwy sposób ustawiają kod odpowiedzi na 500. Zwykle wystarcza im nie przeszkadzać, a jeśli już skrypt przechwytuje wyjątki lub obsługuje po swojemu sytuacje błędne, to trzeba je obsłużyć do końca, włącznie z odesłaniem odpowiedniego kodu.
Need more information? Do not hesitate to ask!marcin@elksoft.pl.