Protokół HTTP w wersji 1.1, opisany w dokumencie RFC 2068, jest faktycznym standardem przesyłu dokumentów WWW. Protokół ten jest ogólny i bezpaństwowy, i został zaprojektowany w taki sposób, aby był rozszerzalny do prawie każdego formatu dokumentu. Działa on poprzez połączenia protokołu TCP, zazwyczaj wykorzystując port 80, chociaż można określić inny port (na przykład 8080). Po ustanowieniu połączenia, klient transmituje do serwera komunikat żądania, a ten wysyła odpowiedź. Protokół HTTP jest zazwyczaj wykorzystywany przez takie aplikacje, jak przeglądarki.

Najprostszą funkcją, lub metodą, protokołu HTTP jest GET, która pobiera informacje zapamiętane w witrynie WWW, lub na serwerze WWW. Jednak systemy informacyjne o pełnych możliwościach wymagają szerszego zestawu funkcji, łącznie z wyszukiwaniem, uaktualnianiem oraz przypisami. Protokół HTTP zapewnia zestaw metod sygnalizujących cel danego żądania. Wykorzystuje on ujednolicony identyfikator zasobów (URI) albo jako ujednolicony lokalizator zasobów (URL), albo jako ujednoliconą nazwę zasobów (URN), aby wskazać zasób, wobec którego ma zostać zastosowana metoda. Komunikaty są przekazywane w formacie podobnym do tego, który wykorzystuje poczta internetowa, zdefiniowanym przez standard uniwersalnych rozszerzeń internetowej poczty elektronicznej (MIME) — odwołaj się do dokumentów RFC od 2045 do 2049.

Protokół HTTP jest również używany do komunikacji pomiędzy agentami użytkownika a bramami do innych systemów internetowych, łącznie z tymi, które są obsługiwane przez protokoły SMTP, NNTP oraz FTP. W ten sposób umoż liwia on podstawowy dostęp hipermedialny do zasobów dostępnych z różnorodnych aplikacji.

Metody HTTP

Dokument RFC 2616 definiuje zestaw wspólnych metod HTTP. Dokument ten nie wyklucza dodatkowych metod, ale przestrzega, iż metody spoza wspólnej listy „mogą nie posiadać takiej samej semantyki dla oddzielnie rozszerzonych klientów i serwerów”. Innymi słowy, jeżeli zdefiniujesz i będziesz korzystał z dodatkowych metod, to mogą wystąpić niezgodności pomiędzy niektórymi hostami i niektórymi serwerami.

Wspólne metody HTTP są następujące:
OPTIONS — pozwala klientowi ustalić opcje i/lub wymagania związane z danym zasobem, albo możliwości danego serwera, nie implikując działań zasobu i nie inicjując pobierania zasobu.
GET — pobiera informacje (w formie jednostki) zidentyfikowane przez URI, do którego zostało zgłoszone żądanie. Jeżeli URI zidentyfikuje proces wytwarzający dane, to wytworzone dane zostaną zwrócone jako jednostka. Warunkowy komunikat GET zawiera pole nagłówka If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, lub If-Range. Pozwala to na odświeżanie buforowanych jednostek bez potrzeby wielokrotnego przesyłu, czy żądania danych, które są już w posiadaniu klienta. GET częściowy żąda, aby przesłana została tylko część jednostki, określona przez pole nagłówka Range.

HEAD — identyczny z GET, z tym że serwer nie zwraca w odpowiedzi treści komunikatu. Metoda ta uzyskuje informacje dotyczące jednostki nie przesyłając samej treści jednostki i jest wykorzystywana do testowania ważności, dostępności oraz niedawnych modyfikacji łączy hipertekstowych.

POST — żąda, aby serwery przyjmowały jednostkę załączoną w żądaniu, jako nowego podwładnego zasobu zidentyfikowanego przez URI, do którego zostało zgłoszone żądanie (podobnie, jak mówi się, że plik umieszczony w katalogu jest nowym podwładnym tego katalogu). POST jest wykorzystywany do przypisywania zasobów, do wysyłania komunikatów (na przykład do elektronicznego biuletynu informacyjnego), do przedkładania danych formularzy oraz do rozszerzania bazy danych poprzez operację dołączania. Funkcja pełniona przez metodę POST określana jest przez serwer i zazwyczaj jest uzależniona od URI.

PUT — żąda, aby jednostka załączona w żądaniu została zapamiętana pod URI, do którego zostało zgłoszone żądanie. Jeżeli dany zasób wspomniany w URI już istnieje, to przesyłaną jednostkę uznaje się za wersję zmodyfikowaną. Jeżeli URI nie wskazuje na istniejący zasób, a żądający użytkownik może zdefiniować URI jako nowy zasób, to zasób jest tworzony na serwerze.

DELETE — żąda, aby serwer usunął zasób zidentyfikowany przez URI.

TRACE — wywołuje zdalną pętlę zwrotną komunikatu żądania. Ostateczny odbiorca żądania odbija otrzymany komunikat z powrotem do klienta. TRACE pozwala klientowi zobaczyć co jest odbierane na drugim końcu łańcucha żądania. Informacja ta może być wykorzystywana do testowania, lub znajdywania uszkodzeń.

CONNECT — nazwa metody zarezerwowana do wykorzystywania wraz z proxy, który może dynamicznie przełączyć się na pełnienie funkcji tunelu, przy użyciu, na przykład, tunelowania z wykorzystaniem warstwy zabezpieczeń łączy (SSL). Proxy to program pośredniczący, pełniący zarówno funkcję serwera, jak i klienta, w celu zgłaszania żądań w imieniu innych klientów.

Kody stanu protokołu HTTP

Kody stanu HTTP są wykorzystywane przez metody podczas normalnej pracy, albo wysyłane do użytkownika, jeżeli wystąpi błąd. Jest pięć klasyfikacji kodów stanu:
Informacyjny (1xx) — sygnalizuje prowizoryczną (zazwyczaj pośrednią) odpowiedź. Te kody wskazują, że dana metoda przebiega normalnie i miało miejsce oczekiwane zdarzenie. Jeżeli serwer protokołu HTTP 1.1 wykryje klienta protokołu HTTP 1.0, to nie będzie wysyłał komunikatów informacyjnych, ponieważ nie są one zdefiniowane dla HTTP 1.0.
Pomyślny (2xx) — sygnalizuje, że żądanie klienta zostało pomyślnie otrzymane, zrozumiane i przyjęte.
Readresowanie (3xx) — sygnalizuje, że agent użytkownika musi podjąć dalsze działania, aby spełnić żądanie. Działania te mogą być przeprowadzane automatycznie przez agenta użytkownika (jeżeli wykorzystywaną metodą jest GET, lub HEAD) albo mogą wymagać interwencji użytkownika.
Błąd klienta(4xx) — sygnalizuje, że występuje, lub wydaje się, że występuje, błąd klienta. Za wyjątkiem przypadku odpowiadania na żądanie HEAD, komunikat zawiera wyjaśnienie błędu i informuje użytkownika, czy jest on tymczasowy, czy stały.
Błąd serwera (5xx) — sygnalizuje, że serwer zdaje sobie sprawę, iż wygenerował błąd, albo że nie jest w stanie wykonać żądania. Za wyjątkiem przypadku odpowiadania na żądanie HEAD, komunikat zawiera wyjaśnienie błędu i informuje użytkownika, czy jest on tymczasowy, czy stały.

Kody stanu i komunikaty protokołu HTTP
 

Kod stanu	Komunikat	Kod stanu	Komunikat
100	Kontynuuj	404	Nie znaleziony
101	Przełączanie protokołów	405	Metoda niedozwolona
200	OK	406	Nie do przyjęcia
201	Utworzony	407	Wymagane uwierzytelnienie proxy
202	Przyjęty	408	Przeterminowanie żądania
203	Nie autorytatywny	409	Konflikt
204	Bez treści	410	Minęło
205	Resetuj treść	411	Wymagana długość
206	Treść częściowa	412	Warunek wstępny nie powiódł się
300	Wiele opcji	413	Jednostka żądania zbyt duża
301	Przeniesiony na stałe	414	URI żądania zbyt duży
302	Znaleziony	415	Nieobsługiwany typ nośnika
303	Zobacz inny	416	Żądany zakres nie do spełnienia
304	Nie zmodyfikowany	417	Oczekiwanie nie powiodło się
305	Użyj proxy	500	Wewnętrzny błąd serwera
307	Readresowanie tymczasowe	501	Nie zaimplementowany
400	Złe żądanie	502	Zła brama
401	Nieautoryzowany	503	Usługa niedostępna
402	Wymagana opłata	504	Przeterminowanie bramy
403	Wzbroniony	505	Nieobsługiwana wersja HTTP

Struktura pakietów protokołu HTTP
Pakiety protokołu HTTP są, ogólnie rzecz biorąc, wyjątkowo złożone. Zdefiniowanie struktury nagłówka pakietu protokołu HTTP zajmuje 51 stron dokumentu RFC 2616 (paragraf 14, strony 100 do 150).