W dzisiejszym świecie HTTP zyskał niespotykane dotąd znaczenie. Niezależnie od tego, czy ze względu na wpływ na społeczeństwo, politykę, gospodarkę czy kulturę, HTTP jest tematem, który nie pozostawia nikogo obojętnym. Od swoich początków aż do dzisiaj HTTP był przedmiotem badań, debat i kontrowersji. W tym artykule zbadamy różne aspekty HTTP, analizując jego znaczenie w bieżącym kontekście i jego wpływ w różnych obszarach życia codziennego. Ponadto zagłębimy się w jego historię, ewolucję i przyszłe perspektywy, aby dokładnie zrozumieć dzisiejsze znaczenie HTTP.
HTTP (ang. Hypertext Transfer Protocol) – protokół stworzony przez Tima Bernersa-Lee na potrzeby komunikacji między klientem a serwerem w sieci WWW (ang. World Wide Web). Najnowszą specyfikację HTTP stanowi dokument RFC 2616 ↓. Przy pomocy protokołu klienci HTTP komunikują się z serwerami, zamawiając pliki składające się na strony internetowe oraz dostarczają niezbędne do tego informacje, np. treści wprowadzane w formularzach.
Określa on formę żądań klienta (tj. np. przeglądarki www) dotyczących danych oraz formę odpowiedzi serwera na te żądania. W oryginalnych implementacjach był protokołem bezstanowym (ang. stateless), bowiem nie zachowywał żadnych informacji o poprzednich transakcjach z klientem. Pozwalało to znacznie zmniejszyć obciążenie serwera, jednak jest kłopotliwe w sytuacji, gdy np. trzeba zapamiętać konkretny stan dla użytkownika, który wcześniej łączył się już z serwerem. Jeszcze w latach 90. XX wieku firma Netscape wprowadziła początkowo nieformalne, a następnie ustandaryzowane rozszerzenie znane jako ciasteczka. Inne podejścia to m.in. sesje po stronie serwera, ukryte parametry – gdy aktualna strona zawiera formularz – oraz parametry umieszczone w URL-u (jak np. /index.php?userid=3
).
Serwery obsługujące HTTP standardowo nasłuchują na porcie TCP numer 80[1].
W 2015 opublikowana została kolejna wersja protokołu HTTP/2, a w 2022 kolejna HTTP/3.
Metoda CONNECT nie jest częścią standardu HTTP/1.1, jednak jest powszechnie implementowana na podstawie dokumentu internet-draft wygasłego w 1999 roku[2].
GET / HTTP/1.1
(prośba o zwrócenie dokumentu o URI / zgodnie z protokołem HTTP 1.1)Host: example.com
(wymagany w HTTP 1.1 nagłówek Host
służący do rozpoznania hosta, jeśli serwer na jednym IP obsługuje kilka VirtualHostów)User-Agent: Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
(nazwa aplikacji klienckiej)Accept: text/xml,application/xml, application/xhtml+xml, text/html;q=0.9,text/plain;q=0.8
(akceptowane (bądź nieakceptowane dla q=0) przez klienta typy plików)Accept-Language: pl,en-us;q=0.7,en;q=0.3
(preferowany język strony – nagłówek przydatny przy Language negotiation)Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.7
(preferowane kodowanie znaków, patrz strona kodowa)Keep-Alive: 300
(czas, jaki klient chce zarezerwować do następnego zapytania w przypadku połączenia Keep-Alive)Connection: keep-alive
(chęć nawiązania połączenia stałego Keep-Alive z serwerem HTTP/1.0)HTTP/1.1 dopuszcza wysłanie kilku żądań naraz (pipelining). HTTP/1.0 zakłada jedno żądanie i jedną odpowiedź.
HTTP/1.1 200 OK
(kod odpowiedzi HTTP - zaakceptowanie i zwrócenie zawartości)Date: Thu, 20 Dec 2001 12:04:30 GMT
(czas serwera)Server: Apache/2.0.50 (Unix) DAV/2
(opis aplikacji serwera)Set-Cookie: PSID=d6dd02e9957fb162d2385ca6f2829a73; path=/
(nakazanie klientowi zapisania ciasteczka)Expires: Thu, 19 Nov 1981 08:52:00 GMT
(czas wygaśnięcia zawartości zwróconego dokumentu. Data w przeszłości zabrania umieszczenie dokumentu w pamięci podręcznej. Jest to stara metoda zastąpiona przez Cache-Control)Cache-Control: no-store, no-cache, must-revalidate
(no-store zabrania przechowywania dokumentu na dysku, nawet gdy nie jest to pamięć podręczna. must-revalidate nakazuje bezwzględnie stosować się do wytycznych i sprawdzić świeżość dokumentu za każdym razem)Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
(akceptacja połączenia Keep-Alive dla klientów HTTP/1.0)Transfer-Encoding: chunked
(typ kodowania zawartości stosowanej przez serwer)Content-Type: application/xhtml+xml; charset=utf-8
(typ MIME i strona kodowa zwróconego dokumentu)HTTP do obsługi połączeń Keep - Alive wymaga, aby odpowiedź od serwera miała znaną długość (przez podanie Content-Length lub użycie Transfer-Encoding: chunked). W przeciwnym wypadku koniec odpowiedzi sygnalizuje zerwanie połączenia i Keep-Alive nie może działać.
Nagłówek Keep-Alive jest rozszerzeniem HTTP/1.0. W HTTP/1.1 ten nagłówek nie jest potrzebny, gdyż połączenia Keep-Alive są domyślne (zachowanie zmienia Connection: close).