Protokół Transferu Hipertekstu (HTTP)

Wprowadzenie do HTTP

HTTP, czyli Protokół Transferu Hipertekstu, jest protokołem warstwy aplikacji używanym do wymiany dokumentów hipermedialnych, takich jak HTML, między klientami i serwerami WWW. Przeglądarka może dzięki niemu żądać zasobu, a serwer przekazać dokument lub odpowiedź opisującą wynik operacji.

HTTP działa w modelu żądanie-odpowiedź oraz w oparciu o model klient-serwer. Klient, na przykład przeglądarka, wysyła komunikat żądania. Serwer przetwarza żądanie i odsyła komunikat odpowiedzi, który może zawierać dokument HTML, obraz albo kod statusu. HTTP/2 i HTTP/3 pozwalają obsługiwać wiele strumieni w ramach połączenia, lecz każdy komunikat ma rolę żądania albo odpowiedzi.

Analiza adresu internetowego: Uniform Resource Locator (URL)

Przed wysłaniem żądania klient potrzebuje odwołania do zasobu. URL (Uniform Resource Locator) jest szczególnym typem URI (Uniform Resource Identifier), który wskazuje zasób i sposób dostępu do niego. Składnia obejmuje między innymi schemat, authority, ścieżkę, zapytanie i fragment. Authority może zawierać nazwę hosta oraz opcjonalny port, a ścieżka wskazuje zasób niezależnie od jego formatu. URI może zawierać także komponent user-information, lecz dane uwierzytelniające w adresie należy traktować ostrożnie. Przykład adresu URL to http://www.cisco.com/web-server.htm.

1. Schemat: http:

   To pierwsza część adresu URL i określa protokół używany do komunikacji. W tym przykładzie jest to $http$. Schemat $https$ wskazuje użycie HTTP przez TLS. Po schemacie występują dwukropek i dwa ukośniki (://).

2. Host: www.cisco.com

   Host identyfikuje serwer, na którym znajduje się zasób. Nazwa domenowa odpowiada numerycznemu adresowi IP, na przykład $2.22.112.115$. System DNS (Domain Name System) tłumaczy nazwę na adres używany przez protokół IP.

3. Ścieżka: /web-server.htm

   Ścieżka wskazuje zasób na serwerze. Gdy URL zawiera komponent authority, ścieżka jest pusta albo zaczyna się pojedynczym ukośnikiem. W tym przykładzie ścieżka ma wartość /web-server.htm.

4. Komponenty opcjonalne (nie w tym przykładzie):
   • Port: Numer portu usługi na serwerze. HTTP domyślnie używa portu $80$, a HTTPS portu $443$. Inny port podaje się po hoście, po dwukropku, na przykład :8080.
   • Ciąg zapytania (query): Zaczyna się od znaku zapytania (?) i może przenosić dane do serwera, często jako pary klucz-wartość, na przykład ?szukaj=sieci&strona=2. HTTP nie określa jednego limitu długości. Ograniczenia wynikają z klienta, serwera i urządzeń pośrednich.
   • Fragment: Zaczyna się od symbolu krzyżyka (#) i wskazuje część zasobu, na przykład #sekcja2. Fragment jest przetwarzany przez klienta i nie jest wysyłany w żądaniu HTTP.

Cykl żądania i odpowiedzi HTTP

Każdy komunikat HTTP jest żądaniem albo odpowiedzią. W HTTP/1.1 komunikat składa się z linii początkowej, nagłówków, pustej linii i opcjonalnego ciała. Pusta linia oddziela nagłówki od ciała, a pola takie jak Content-Length lub Transfer-Encoding pomagają ustalić sposób odczytu treści. Odpowiedź może zawierać tymczasowy kod 1xx przed odpowiedzią końcową. Niektóre odpowiedzi, w tym odpowiedzi na HEAD, nie zawierają treści wiadomości, nawet gdy odpowiadające żądanie GET zwróciłoby ciało. W HTTP/2 i HTTP/3 wiele strumieni może być obsługiwanych współbieżnie. Poniżej przedstawiono strukturę komunikatów.

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 ...
Accept-Language: pl-PL
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 200 OK
Date: Mon, 23 May 2025 22:38:34 GMT
Server: Apache/2.4.1 (Unix)
Content-Type: text/html; charset=UTF-8
Content-Length: 122

<!DOCTYPE html>
<html>
...
</html>

Metody HTTP

Metody HTTP określają zamierzoną operację klienta na zasobie. Ich właściwości bezpieczeństwa i idempotencji opisują zamierzony skutek, choć serwer może wykonywać logowanie lub inne działania wewnętrzne. Metoda bezpieczna ma zamierzony skutek odczytowy, a metoda idempotentna po powtórzeniu powinna prowadzić do tego samego zamierzonego stanu. Kolejne żądania mogą jednak zwrócić inne reprezentacje lub kody statusu. Poniższe metody są często używane w komunikacji internetowej.

GET

Żądanie $GET$ służy do pobierania reprezentacji zasobu. Wpisanie adresu URL w przeglądarce zwykle powoduje wysłanie GET. Metoda jest bezpieczna w rozumieniu HTTP, czyli jej zamierzony skutek dla zasobu ma charakter odczytu, choć serwer może wykonywać dodatkowe działania, takie jak logowanie. Dane w GET mogą być umieszczone w ciągu zapytania, który jest widoczny w adresie. Limity długości wynikają z implementacji.

POST

Żądanie $POST$ służy do przekazania danych do przetworzenia przez serwer, często w celu utworzenia zasobu. Formularz kontaktowy może wysłać dane w ciele żądania POST. Umieszczenie danych w ciele nie zapewnia poufności. Do ochrony poufnych danych potrzebny jest TLS, a rozmiar nadal zależy od implementacji. POST nie jest metodą bezpieczną, a specyfikacja nie definiuje go jako idempotentnego. Powtórzenie może utworzyć więcej niż jeden zasób, zależnie od implementacji. Nie jest idempotentne w sensie HTTP, dlatego powtórzenie nie musi prowadzić do tego samego stanu zasobu.

PUT

Metoda $PUT$ służy do utworzenia lub zastąpienia reprezentacji zasobu pod wskazanym adresem. Jej zamierzony skutek jest idempotentny, więc wielokrotne wysłanie tego samego żądania powinno prowadzić do tego samego stanu zasobu, choć odpowiedzi mogą się różnić.

DELETE

Metoda $DELETE$ żąda usunięcia wskazanego zasobu. Jej zamierzony skutek jest idempotentny. Kolejne żądania powinny pozostawiać stan bez dalszej zmiany, choć serwer może zwrócić inne kody odpowiedzi.

HEAD

Metoda $HEAD$ ma semantykę GET, lecz odpowiedź nie zawiera ciała. Służy do pobrania nagłówków zasobu, na przykład w celu sprawdzenia jego istnienia, rozmiaru lub daty modyfikacji bez pobierania zawartości.

Kody statusu HTTP

Każda odpowiedź HTTP zawiera trzycyfrowy kod statusu opisujący wynik przetwarzania żądania. Kody z zakresu 100-599 dzielą się na pięć klas według pierwszej cyfry. Klient, który nie zna konkretnego kodu, interpretuje go zgodnie z klasą. Na przykład odpowiedź 204 nie zawiera treści, a 304 wskazuje, że reprezentacja przechowywana w pamięci podręcznej pozostaje aktualna. Kod statusu opisuje wynik żądania, lecz diagnostyka aplikacji wymaga dodatkowych danych odpowiedzi. Tekstowy opis, jeśli jest przekazywany, pomaga człowiekowi, a wynik określają kod i jego semantyka.

• 1xx (Informacyjne): Odpowiedź tymczasowa informuje o postępie lub oczekiwaniu na dalsze przetwarzanie. Po niej może wystąpić odpowiedź końcowa. Przykład: $100 Continue$.
• 2xx (Sukces): Żądanie zostało pomyślnie odebrane, zrozumiane i zaakceptowane.
  • $\text{200 OK}$: Żądanie zakończyło się pomyślnie. Ciało odpowiedzi może zawierać reprezentację zasobu.
  • $\text{201 Created}$: Żądanie zakończyło się sukcesem i utworzyło nowy zasób, na przykład po POST.
• 3xx (Przekierowanie): Klient musi wykonać dodatkowe działanie, aby zakończyć żądanie, zgodnie z informacją w odpowiedzi.
  • $\text{301 Moved Permanently}$: Zasób został trwale przeniesiony pod nowy adres. Klient może zaktualizować zapisane odwołania.
  • $\text{302 Found}$: Zasób jest tymczasowo dostępny pod innym adresem. Klient może nadal używać pierwotnego adresu w kolejnych żądaniach.
• 4xx (Błąd żądania): Serwer nie może lub nie chce zrealizować żądania z powodu problemu postrzeganego po stronie żądania.
  • $\text{400 Bad Request}$: Serwer odrzuca żądanie z powodu błędu, na przykład nieprawidłowej składni.
  • $\text{403 Forbidden}$: Serwer odmawia realizacji żądania, na przykład z powodu reguł dostępu.
  • $\text{404 Not Found}$: Serwer nie znalazł bieżącej reprezentacji wskazanego zasobu.
• 5xx (Błąd serwera): Serwer wie, że wystąpił błąd lub nie może zrealizować pozornie prawidłowego żądania.
  • $\text{500 Internal Server Error}$: Ogólny kod błędu używany, gdy żaden bardziej szczegółowy opis nie pasuje.
  • $\text{503 Service Unavailable}$: Serwer jest czasowo niezdolny do obsługi żądania, na przykład z powodu konserwacji lub przeciążenia.

Ewolucja HTTP

HTTP rozwijał się wraz ze wzrostem liczby zasobów i wymagań dotyczących komunikacji. HTTP/1.0 opisano w RFC 1945 z 1996 roku, a HTTP/1.1 w RFC 2068 z 1997 roku. Kolejne wersje dodawały nagłówki, kody statusu, trwałe połączenia i mechanizmy efektywniejszego przesyłania. Semantyka metod i kodów pozostaje wspólną warstwą znaczeniową, nawet gdy sposób przenoszenia komunikatów zależy od wersji HTTP.

HTTP/0.9 - protokół jednoliniowy (1991)

Pierwsza wersja była prosta. Żądanie składało się z jednej linii zawierającej metodę $GET$ i ścieżkę zasobu. Odpowiedź zawierała plik HTML bez nagłówków, kodów statusu i innych metadanych.

HTTP/1.0 - rozszerzenie formatu (1996)

Ta wersja dodała nagłówki żądań i odpowiedzi, kody statusu oraz możliwość przesyłania typów zawartości innych niż HTML, takich jak obrazy i wideo. W typowym użyciu każde żądanie otwierało nowe połączenie TCP, co zwiększało koszt stron z wieloma zasobami.

HTTP/1.1 - standard (1997)

HTTP/1.1 wprowadził między innymi połączenia trwałe, które są domyślne w HTTP/1.1 i pozwalają obsługiwać wiele żądań na jednym połączeniu TCP. Wersja ta definiuje również potokowość żądań, transfer porcjowany oraz obowiązkowy nagłówek Host. Nagłówek Keep-Alive był wcześniej używany jako rozszerzenie HTTP/1.0.

Zabezpieczanie sieci: HTTPS

Na początku rozwoju WWW ruch HTTP nie był chroniony kryptograficznie. Osoba obserwująca ruch mogła odczytać dane wymieniane między przeglądarką a serwerem. HTTPS oznacza HTTP używany z ochroną TLS (Transport Layer Security). TLS zapewnia poufność i integralność rekordów, a walidacja certyfikatu wiąże serwer z nazwą w adresie.

HTTPS jest HTTP przenoszonym przez warstwę ochronną. Ochronę zapewnia protokół TLS (Transport Layer Security), wcześniej znany jako SSL (Secure Sockets Layer).

Uproszczony przebieg wygląda następująco:

1. Weryfikacja certyfikatu: Serwer przedstawia certyfikat TLS. Certyfikat wiąże tożsamość serwera z kluczem publicznym, a klient sprawdza jego łańcuch zaufania oraz zgodność nazwy.
2. Uzgadnianie (handshake): Klient i serwer uzgadniają parametry TLS oraz klucze sesji. W TLS 1.3 serwer uwierzytelnia się między innymi komunikatami Certificate, CertificateVerify i Finished.
3. Szyfrowana komunikacja: Po uzgodnieniu kluczy późniejsze rekordy TLS chronią ruch HTTP przed odczytem i modyfikacją. Zakres ochrony zależy od poprawnej walidacji certyfikatu i konfiguracji TLS.

Przeglądarka sygnalizuje stan połączenia TLS, gdy klient używa adresu https://. Ocena bezpieczeństwa zależy od poprawnej walidacji certyfikatu i parametrów połączenia.

Wyzwanie stanu w protokole bezstanowym

Jedną z zasad HTTP jest protokół bezstanowy. Każde żądanie powinno zawierać informacje potrzebne do jego obsługi, bez wymogu odtwarzania poprzednich żądań. Nagłówki Authorization i Cookie mogą przenosić dane potrzebne do rozpoznania klienta. Serwer może jednak przechowywać stan aplikacji i identyfikować go za pomocą danych dostarczanych przez klienta.

Taki model upraszcza obsługę niezależnych żądań, lecz aplikacje internetowe często potrzebują sesji, koszyka lub stanu logowania. Te informacje trzeba powiązać z kolejnymi żądaniami.

Jednym z mechanizmów są ciasteczka HTTP (cookies). Serwer wysyła ciasteczko w nagłówku odpowiedzi (Set-Cookie). Przeglądarka przechowuje je i dołącza w nagłówku żądania (Cookie) tylko wtedy, gdy pasują reguły domeny, ścieżki i atrybutów bezpieczeństwa. Atrybuty Domain, Path, Max-Age, Secure i HttpOnly ograniczają zakres użycia oraz dostęp skryptów. Ciasteczko może zawierać identyfikator sesji, który pozwala serwerowi odszukać stan użytkownika. Sam mechanizm ciasteczek nie zmienia bezstanowej semantyki HTTP, tylko przenosi identyfikator stanu w kolejnych żądaniach.