Z www czy bez, HTTP czy HTTPS: sprawdzanie czterech adresów witryny

Dla publicznej witryny HTTP i HTTPS w połączeniu z domeną bazową oraz hostem www dają cztery częste adresy wejściowe. Rozwiązywanie nazw (DNS), szyfrowany transport (TLS) i reguły serwera określają dostępność oraz adres końcowy. Te cztery kombinacje są użyteczną listą kontrolną, a nie wszystkimi możliwymi adresami domeny.

Przykład z datą: 2 września 2026 r.

Zarchiwizowany pomiar obejmuje dwanaście domen i cztery warianty każdej domeny. W dziewięciu grupach wszystkie cztery warianty mają ten sam końcowy URL. Trzy grupy różnią się: kernel.org i apache.org zachowują osobne cele dla www i domeny bazowej, a nginx.org osobne cele HTTP i HTTPS. Zgodność adresów nie potwierdza poprawnego dostarczenia strony: zapisany łańcuch HTTP dla domeny bazowej stackoverflow.com kończy się kodem 403.

Dla dwunastu wejść HTTP przez domenę bazową zapis obejmuje siedem łańcuchów z jednym przekierowaniem, cztery z dwoma oraz jedną odpowiedź bez przekierowania. Te liczby dotyczą tego wariantu wejścia, a nie wszystkich 48 testów. Dane opisują odpowiedzi zaobserwowane w podanym dniu. Nie określają aktualnej konfiguracji, powodów decyzji ani ogólnych skutków dla pozycji w wyszukiwarce.

Pochodzenie i zakres cookies to różne granice

http://example.com oraz https://www.example.com mają różne pochodzenie (origin) z powodu schematu i hosta. Origin łączy schemat, host i port. Pamięć przeglądarki przypisana do origin pozostaje oddzielna. Cookies podlegają innym regułom: bez atrybutu Domain cookie jest ograniczone do bieżącego hosta, także w domenie bazowej. Z Domain=example.com cookie może obejmować domenę nadrzędną i subdomeny; dozwolone cookie dla domeny nadrzędnej może powstać również na www.example.com. Secure, Path i inne atrybuty nakładają dodatkowe warunki. Sam wybór www nie zapobiega współdzieleniu cookies.

Preferowany adres bez obietnic rankingowych

Dla równoważnych publicznych stron jeden cel HTTPS upraszcza nawigację, linkowanie i utrzymanie. Google może rozpoznać duplikaty oraz wybrać adres kanoniczny bez jawnej preferencji. To główny adres reprezentujący te kopie w wyszukiwarce. Kilka dostępnych kopii nie oznacza więc automatycznie dwóch wpisów w indeksie ani trwale rozdzielonych sygnałów z linków.

Trwałe przekierowania i rel="canonical" są silnymi sygnałami wyboru adresu kanonicznego. Linki wewnętrzne i mapy witryny powinny zgadzać się z zamierzonym celem. Oznaczenie canonical nie przekierowuje odwiedzającego ani nie szyfruje połączenia HTTP; nie gwarantuje również wyboru Google. Parametry zmieniające istotną treść nie powinny automatycznie znikać z kanonicznej wersji.

Zarówno 301, jak i 308 oznaczają trwałe przeniesienie. W odróżnieniu od historycznie możliwej obsługi 301 kod 308 zachowuje metodę i treść żądania. Formularze logowania, punkty końcowe POST oraz API wymagają więc osobnej oceny. Przekierowania tymczasowe mogą być prawidłowe w sytuacjach przejściowych.

Certyfikaty i celowy drugi skok

Każdy odwiedzany host HTTPS wymaga poprawnej obsługi TLS przed odczytaniem przekierowania HTTP. Jeden certyfikat może obejmować obie nazwy, ale możliwe są również osobne, poprawnie skonfigurowane certyfikaty. Przekierowanie nie zastępuje działającego DNS, osiągalnego punktu TLS ani pasującego certyfikatu.

Bezpośrednie przejście z http://example.com/path na https://www.example.com/path oszczędza jeden skok sieciowy. Taka wizyta nie ustanawia jednak HSTS dla example.com: polityka odebrana z www nie działa w górę na domenę nadrzędną. Świadoma alternatywa to najpierw HTTP na HTTPS na tym samym hoście, a następnie zmiana hosta. Pośrednia odpowiedź HTTPS może ustawić politykę pierwotnego hosta. Dwa skoki nie oznaczają zatem automatycznie błędu konfiguracji.

HSTS należy do odpowiedzi HTTPS

Strict Transport Security nakazuje obsługującym mechanizm przeglądarkom zmieniać przyszłe połączenia HTTP na HTTPS w zakresie polityki. Nagłówek odebrany przez HTTP jest ignorowany; poprawne przekierowanie HTTPS może zawierać skuteczny nagłówek. Polityka nie jest ograniczona do końcowej odpowiedzi z treścią.

Wdrożenie wymaga sprawdzonej obsługi HTTPS i odpowiedniego krótkiego okresu próbnego. includeSubDomains rozszerza politykę na zagnieżdżone subdomeny i musi odpowiadać obsługiwanej infrastrukturze. Polityka hosta podrzędnego nie chroni domeny nadrzędnej. Późniejsza odpowiedź z max-age=0 usuwa zapisaną politykę tego hosta, ale nie znosi niezależnie obowiązującej polityki nadrzędnej ani nie usuwa natychmiast wpisu preload z przeglądarki.

Preloading umieszcza domenę na liście dostarczanej z przeglądarką. Obowiązek HTTPS działa wtedy już przed pierwszą wizytą. To osobna, długoterminowa decyzja, a nie automatyczny kolejny etap. Projekt listy preload obecnie zaleca HSTS, lecz nie zaleca ogólnie preloadingu. Przyjęcie na listę nadal wymaga między innymi przekierowania HTTP na HTTPS na tym samym hoście, poprawnego HTTPS w subdomenach i odpowiednich dyrektyw nagłówka. Automatyczne aktualizowanie połączeń do HTTPS i istniejące wpisy preload oznaczają również, że pierwsza wizyta bez wpisanego schematu nie musi zaczynać się od sieciowego żądania HTTP.

Cztery kontrole z konkretnymi dowodami

Poniższy przykład powłoki wykonuje GET dla każdego zarezerwowanego adresu przykładowego i wypisuje nagłówki oraz kolejny cel przekierowania. Celowo nie podąża automatycznie za przekierowaniami. Domena wymaga zastąpienia rzeczywistym publicznym celem testu.

for url in \
  'http://example.com/' 'https://example.com/' \
  'http://www.example.com/' 'https://www.example.com/'
do
  printf '\n%s\n' "$url"
  curl --silent --show-error --connect-timeout 10 --max-time 20 \
    --dump-header - --output /dev/null \
    --write-out 'status=%{http_code} next=%{redirect_url}\n' "$url"
done

Każdy cel Location wymaga potem osobnej kontroli aż do odpowiedzi końcowej lub udokumentowanego błędu. Ograniczony łańcuch, czas pomiaru, metody HTTP, końcowy status, błędy TLS i dokładne adresy zapewniają odtwarzalność. HEAD z -I może zachowywać się inaczej niż GET. Klient wiersza poleceń nie odtwarza automatycznie zapisanego HSTS, buforowanych przekierowań, cookies ani nawigacji JavaScript z przeglądarki.

Wszystkie cztery udane wyniki muszą prowadzić do zamierzonego równoważnego zasobu, a nie tylko dwie osiągalne wersje. Zamiana ścieżek lub wartości zapytania na małe litery może ukryć rzeczywiste różnice. Sam końcowy status 200 nie potwierdza jeszcze poprawnej treści.

Śledzenie łańcucha przekierowań i hosta kanonicznego zapisuje serwerowe łańcuchy przekierowań i wskazuje możliwe problemy. Obecne porównanie jest heurystyczne: zgodność osiągalnych wariantów nie dowodzi powodzenia wszystkich czterech, a porównywanie URL zbyt szeroko normalizuje ścieżki. Dokładne adresy i błędy wymagają kontroli. Kod tymczasowy albo dwa skoki są wskazówką do sprawdzenia, a nie dowodem usterki.

Redirect permanent "/" "https://example.com/"

Źródła

• RFC 6797: HTTP Strict Transport Security
• MDN: Korzystanie z cookies HTTP
• Wyszukiwarka Google: Adresy kanoniczne i łączenie duplikatów
• Wyszukiwarka Google: Przekierowania
• MDN: Strict-Transport-Security
• Chromium: Wymagania i zalecenia dotyczące listy HSTS preload
• Chromium: HTTPS jako ustawienie domyślne
• Apache HTTP Server: Przekierowywanie i mapowanie adresów
• Apache HTTP Server: Dyrektywa Redirect
• MDN: Przekierowania w HTTP
• curl: Podręcznik