Wyszukiwanie nagłówków HTTP

Wyszukiwanie nagłówków HTTP to bezpłatne narzędzie, które pobiera wszystkie nagłówki odpowiedzi HTTP zwracane przez adres URL w przypadku typowego żądania GET.

Czym są nagłówki odpowiedzi HTTP?

Nagłówki odpowiedzi HTTP to metadane wysyłane przez serwer WWW przed treścią odpowiedzi, na przykład stroną HTML, obrazem lub dokumentem JSON. Informują klienta, jak ma interpretować i buforować odpowiedź, obsługiwać przekierowania oraz stosować zabezpieczenia.

Odpowiedź HTTP/1.x zwykle zaczyna się od wiersza statusu HTTP, po którym następują nagłówki. W HTTP/2 i HTTP/3 odpowiednik statusu jest przekazywany w pseudonagłówku :status. Wiersz statusu HTTP/1.x jest technicznie oddzielony od nagłówków, ale często wyświetla się go razem z nimi, ponieważ wskazuje, czy żądanie zakończyło się powodzeniem. Status 200 oznacza, że zasób został zwrócony, 301 lub 302 wskazuje przekierowanie, 404 oznacza, że zasobu nie znaleziono, a 500 informuje o błędzie po stronie serwera.

Nagłówki mogą pochodzić z serwera źródłowego, odwrotnego serwera proxy albo sieci dostarczania treści, takiej jak Cloudflare. Niektóre z nich są dodawane lub usuwane podczas przechodzenia odpowiedzi przez te systemy. Wynik może więc opisywać nie tylko aplikację, która wygenerowała stronę.

Jak sprawdzić nagłówki HTTP?

Wpisz pełny adres URL, który chcesz sprawdzić, wraz ze schematem, na przykład https://www.example.com/account. Narzędzie wysyła ze swojego serwera typowe żądanie GET i zwraca nagłówki HTTP otrzymane z podanego adresu.

Aby dokładnie porównać nagłówki odpowiedzi, sprawdzaj konkretne warianty adresu URL, które chcesz przeanalizować. Nagłówki dla http://example.com, https://example.com i https://www.example.com mogą się różnić, ponieważ każdy z tych adresów może mieć własne przekierowania, reguły buforowania i konfigurację serwera.

Składnia adresu URL również wpływa na żądanie:

• Spacje nie są dozwolone jako niezakodowane znaki adresu URL. Zwykle trzeba je zakodować procentowo, najczęściej jako %20 w ścieżce.
• Znak ? rozpoczyna część zapytania, natomiast & i = są powszechnie używane w kodowaniu zapytań typowym dla formularzy, choć nie pełnią tych funkcji w każdym ciągu zapytania.
• Nazwy domen ze znakami diakrytycznymi lub znakami spoza alfabetu łacińskiego są przetwarzane przy użyciu IDNA i przedstawiane jako etykiety A w ASCII, zwykle zaczynające się od xn--. Znaki w ścieżce są natomiast na ogół kodowane jako bajty UTF-8, a następnie procentowo.
• Fragment rozpoczynający się od # jest obsługiwany przez przeglądarkę i nie trafia do żądania HTTP.
• Nie ma jednego, uniwersalnego limitu długości adresu URL. Bardzo długie adresy mogą zostać odrzucone przez serwer, serwer proxy lub aplikację.

Jak odczytać wynik sprawdzania nagłówków HTTP?

Sprawdź nagłówki powiązane z analizowanym problemem. W nazwach nagłówków wielkość liter nie ma znaczenia, ale składnia ich wartości może ją rozróżniać.

Inne nagłówki mogą być charakterystyczne dla konkretnej aplikacji. Na przykład Access-Control-Allow-Origin określa, które źródła mogą odczytywać odpowiedź za pomocą międzydomenowych żądań przeglądarki. Nagłówek Server może wskazywać oprogramowanie lub serwer proxy, ale nie jest wiarygodnym dowodem na użycie danej platformy, ponieważ administratorzy mogą go zmienić albo usunąć.

Praktyczne sposoby diagnozowania problemów

Problemy z przekierowaniami to jeden z częstych powodów sprawdzania nagłówków. Załóżmy, że https://example.com/old-page zwraca status 301 z nagłówkiem Location: https://example.com/new-page. Oznacza to, że serwer nakazuje klientowi wysłać żądanie pod nowy adres. Kolejne sprawdzanie każdego adresu docelowego może ujawnić pętlę przekierowań lub nieoczekiwane przejście między HTTP a HTTPS.

Jeśli strona obsługiwana przez Cloudflare lub inną sieć CDN wyświetla nieaktualną treść, sprawdź Cache-Control, Age, ETag oraz nagłówki pamięci podręcznej właściwe dla danego dostawcy. Wysoka wartość Age oznacza obliczony wiek odpowiedzi w pamięci podręcznej, potencjalnie obejmujący czas spędzony w nadrzędnych pamięciach podręcznych, a nie okres przechowywania jej przez konkretnego pośrednika. Nie dowodzi też, że każda regionalna pamięć podręczna zawiera tę samą wersję.

Jeśli API działa w skrypcie po stronie serwera, ale nie w przeglądarce, sprawdź Content-Type oraz nagłówki odpowiedzi CORS, w tym Access-Control-Allow-Origin. Punkt końcowy JSON zwracający text/html może w rzeczywistości udostępniać stronę błędu lub ekran logowania. Brak uprawnienia do żądań między źródłami może spowodować, że przeglądarka zablokuje dostęp, nawet jeśli serwer zwrócił status 200.

Nagłówki pomagają również diagnozować witrynę, która wydaje się niedostępna. Odpowiedź 503 wskazuje na tymczasową awarię serwera lub systemu nadrzędnego, natomiast 404 oznacza, że nie znaleziono żądanej ścieżki. Nagłówki nie pozwalają jednak rozpoznać każdego problemu. Jeśli rozpoznawanie DNS, połączenie TCP lub negocjacja TLS nie powiedzie się przed utworzeniem odpowiedzi HTTP, może nie być żadnych nagłówków odpowiedzi do sprawdzenia. Ping umożliwia osobne sprawdzenie łączności, a Sprawdzanie HTTP/2 pozwala zweryfikować obsługę protokołu.

Dlaczego prawidłowy wynik może wyglądać na błędny?

Prawidłowy wynik może różnić się od tego, co pokazuje przeglądarka, ponieważ pamięci podręczne, rekordy DNS i kontekst żądania mogą kierować oba żądania do różnych odpowiedzi. Wyszukiwanie nagłówków HTTP działa na serwerze, dlatego może trafić do innego węzła CDN albo wcześniej lub później niż Twoja sieć lokalna rozpoznać niedawno zmieniony rekord DNS.

Przeglądarki wysyłają też własne pliki cookie, akceptowane typy zawartości, języki i walidatory pamięci podręcznej. Strona WordPressa dostępna po zalogowaniu może więc zwracać inne reguły buforowania niż anonimowe żądanie z serwera. Trasowanie geograficzne i systemy zarządzania ruchem botów również mogą zmieniać odpowiedź zależnie od sieci źródłowej lub nagłówków żądania.

Po zmianie DNS resolwery korzystające z pamięci podręcznej mogą nadal używać poprzedniego rekordu, dopóki nie upłynie jego czas życia. Gdy ruch zacznie już docierać do nowego serwera, stary obiekt CDN lub pamięć podręczna przeglądarki może wciąż zwracać wcześniejszą treść. Sprawdź osobno rozpoznany host, w razie potrzeby wyczyść pamięci podręczne i porównaj dokładne adresy URL, zamiast zakładać, że każda nazwa hosta korzysta z tej samej konfiguracji.

Najczęściej zadawane pytania

Czy narzędzie pokazuje nagłówki żądania?

Nie. Pobiera nagłówki odpowiedzi zwracane przez adres URL w przypadku typowego żądania GET. Nagłówki żądania to metadane wysyłane do serwera. Aby sprawdzić je w całości, potrzebujesz osobnych narzędzi deweloperskich przeglądarki, dzienników serwera lub klienta wiersza poleceń.

Czy adresy URL wpisywane w narzędziu są prywatne?

Sprawdzanie odbywa się na serwerze. Wprowadzone dane są przesyłane do tego serwera przez HTTPS i nie są zapisywane. Nie wpisuj adresów URL zawierających hasła, tokeny dostępu ani poufne parametry zapytania, ponieważ podczas wykonywania żądania serwer docelowy również otrzyma te wartości.

Czy nagłówki HTTP wyjaśnią ostrzeżenie o certyfikacie?

Zwykle same nie wystarczą. Połączenie TLS jest nawiązywane przed wysłaniem odpowiedzi HTTP, dlatego wygasły certyfikat, niezgodność nazwy hosta lub niezaufany wystawca mogą uniemożliwić zwrócenie jakichkolwiek nagłówków. Jeśli ostrzeżenie przeglądarki pojawia się przed wczytaniem strony, sprawdź osobno certyfikat i jego łańcuch.

Dlaczego odpowiedź zawiera kilka nagłówków Set-Cookie?

Odpowiedź może ustawiać więcej niż jeden plik cookie, a każdy z nich korzysta z własnego pola Set-Cookie. Nie łącz ich tak, jakby tworzyły listę rozdzielaną przecinkami, ponieważ daty wygaśnięcia plików cookie również mogą zawierać przecinki. Sprawdź osobno domenę, ścieżkę i atrybuty bezpieczeństwa każdego pliku cookie.

Czy mogę porównać wynik z curl?

Tak. Polecenie takie jak curl -D - https://example.com/ -o /dev/null wyświetla nagłówki odpowiedzi i odrzuca jej treść. Wersja curl, nagłówki żądania, ustawienia przekierowań i lokalizacja sieciowa mogą wpływać na wynik. Zanim uznasz różnicę za błąd serwera, upewnij się więc, że warunki są takie same.