HTTP stanowi {{Glossary("protokół")}}, który umożliwia przechwytywanie zasobów, np. dokumentów HTML. Stanowi podstawę każdej wymiany danych w Internecie i jest protokołem klient-serwer, co oznacza, że żądania są inicjowane przez odbiorcę, przeważnie przeglądarkę internetową. Kompletny dokument jest rekonstruowany z różnych przechwyconych subdokumentów, np. tekstu, opisu szablonu, obrazków, video, skryptów itd.
Klienci i serwery komunikują się poprzez wymianę pojedynczych komunikatów (w przeciwieństwie do strumienia danych). Komunikaty wysyłane przez klienta, przeważnie przeglądarkę internetową, nazywane są żądaniami, a wiadomości wysyłane w odpowiedzi przez serwer odpowiedziami.
Zaprojektowany na początku lat 90. HTTP jest protokołem elastycznym, który wyewoluował na przetrzeni czasu. Jest to protokół warstwy aplikacji, który jest wysyłany nad {{Glossary("TCP")}} lub nad połączeniem TCP zaszyfrowanym w {{Glossary("TLS")}}, chociaż dowolny, godny zaufania protokół transportu mógłby zostać teoretycznie użyty. Z powodu swojej rozszerzalności używany jest nie tylko do przechwytywania dokumentów hipertekstowych, ale również do obrazów i video, bądź do dodawania treści na serwery, jak dane wprowadzane do formularzy HTML. HTTP może być również używany do przechwytywania części dokumentów, aby na żądanie aktualizować strony WWW.
HTTP to protokół klient-serwer: żądania są wysyłane przez jedną jednostkę, agenta użytkownika (lub proxy w jego imieniu). Przeważnie użytkownika jest jednoznaczny z przeglądarką, ale tak naprawdę może być wszystkim, np. robotem przemierzającym sieć, by rozpowszechnić i utrzymywać indeks wyszukiwarki.
Każde indywidualne żądanie jest wysyłane na serwer, który je obsługuje i dostarcza informację zwrotną, zwaną odpowiedzią. Pomiędzy klientem a serwerem znajduje się wiele jednostek, kolektywnie nazywanych {{Glossary("Proxy_server", "proxies")}}, które zajmują się różnymi operacjami i funkcjonują jako bramki lub np. {{Glossary("Cache", "caches")}}.
W rzeczywistości pomiędzy przeglądarką i serwerem istnieje więcej komputerów obsługujących żądania: są to routery, modemy itd. Dzięki temu, że układ sieci jest warstwowy, znajdują się one w warstwach sieci i transportu. HTTP znajduje się na samej górze, w warstwie aplikacji. Mimo, że diagnoza problemów pojawiających się sieci jest bardzo istotna, warstwy znajdujące się poniżej przeważnie są nieistotne przy opisie HTTP.
User-agent to każde narzędzie, które działa w imieniu użytkownika. Najczęściej jest nim przeglądarka internetowa, mogą to byc także programy używane przez programistów do debugowania ich aplikacji.
Przegladarka jest zawsze jednostką inicjującą żądanie. Nigdy nie jest nim serwer (jednakże na przestrzeni lat, niektóre mechanizmy zostały dodane, w celu symulacji wiadomości inicjowanych przez serwer)
Aby zaprezentować stronę internetowa, przeglądarka wysyła orginalne żądanie, aby wydobyć dokument HTML, który reprezentuje tę stronę. Przeglądarka analizuje plik, robiąc tworząc dodatkowe żądania korespondujące ze skryptami, informacją o układzie strony do wyświetlenia (CSS), i pod zasobami zawartymi w stronie (najczęściej obrazy i wideo). Następnie przeglądarka łączy te zasoby aby zaprezentować uzytkownikowi kompletny dokument - stronę internetową. Skrypty wykonywane przez przeglądarkę mogą wydobywać więcej zasobów w kolejnych fazach oraz odpowiednio aktualizować stronę.
Strona internetowa jest documentem hipertekstowym. To znaczy niektórę części wyświetlanego tekstu są linkami, które mogą być aktywowane (najczęściej przez kliknięcie) aby włączyć nową strone internetową, pozwalającymi uzytkownikowi kierować jego user-agentów i nawigować w sieci. Przeglądarka tłumaczy te wytyczne poprzez żądania HTTP a następnie interpretuje odpowiedzi HTTP aby przedstawić użytkownikowi jasną odpowiedź
On the opposite side of the communication channel, is the server, which serves the document as requested by the client. A server appears as only a single machine virtually: this is because it may actually be a collection of servers, sharing the load (load balancing) or a complex piece of software interrogating other computers (like cache, a DB server, or e-commerce servers), totally or partially generating the document on demand.
A server is not necessarily a single machine, but several server software instances can be hosted on the same machine. With HTTP/1.1 and the {{HTTPHeader("Host")}} header, they may even share the same IP address.
Between the Web browser and the server, numerous computers and machines relay the HTTP messages. Due to the layered structure of the Web stack, most of these operate at the transport, network or physical levels, becoming transparent at the HTTP layer and potentially making a significant impact on performance. Those operating at the application layers are generally called proxies. These can be transparent, forwarding on the requests they receive without altering them in any way, or non-transparent, in which case they will change the request in some way before passing it along to the server. Proxies may perform numerous functions:
HTTP is generally designed to be simple and human readable, even with the added complexity introduced in HTTP/2 by encapsulating HTTP messages into frames. HTTP messages can be read and understood by humans, providing easier testing for developers, and reduced complexity for newcomers.
Introduced in HTTP/1.0, HTTP headers make this protocol easy to extend and experiment with. New functionality can even be introduced by a simple agreement between a client and a server about a new header's semantics.
HTTP is stateless: there is no link between two requests being successively carried out on the same connection. This immediately has the prospect of being problematic for users attempting to interact with certain pages coherently, for example, using e-commerce shopping baskets. But while the core of HTTP itself is stateless, HTTP cookies allow the use of stateful sessions. Using header extensibility, HTTP Cookies are added to the workflow, allowing session creation on each HTTP request to share the same context, or the same state.
A connection is controlled at the transport layer, and therefore fundamentally out of scope for HTTP. Though HTTP doesn't require the underlying transport protocol to be connection-based; only requiring it to be reliable, or not lose messages (so at minimum presenting an error). Among the two most common transport protocols on the Internet, TCP is reliable and UDP isn't. HTTP therefore relies on the TCP standard, which is connection-based.
Before a client and server can exchange an HTTP request/response pair, they must establish a TCP connection, a process which requires several round-trips. The default behavior of HTTP/1.0 is to open a separate TCP connection for each HTTP request/response pair. This is less efficient than sharing a single TCP connection when multiple requests are sent in close succession.
In order to mitigate this flaw, HTTP/1.1 introduced pipelining (which proved difficult to implement) and persistent connections: the underlying TCP connection can be partially controlled using the {{HTTPHeader("Connection")}} header. HTTP/2 went a step further by multiplexing messages over a single connection, helping keep the connection warm and more efficient.
Experiments are in progress to design a better transport protocol more suited to HTTP. For example, Google is experimenting with QUIC which builds on UDP to provide a more reliable and efficient transport protocol.
This extensible nature of HTTP has, over time, allowed for more control and functionality of the Web. Cache or authentication methods were functions handled early in HTTP history. The ability to relax the origin constraint, by contrast, has only been added in the 2010s.
Here is a list of common features controllable with HTTP.
When a client wants to communicate with a server, either the final server or an intermediate proxy, it performs the following steps:
GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: frHTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html
<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)If HTTP pipelining is activated, several requests can be sent without waiting for the first response to be fully received. HTTP pipelining has proven difficult to implement in existing networks, where old pieces of software coexist with modern versions. HTTP pipelining has been superseded in HTTP/2 with more robust multiplexing requests within a frame.
HTTP messages, as defined in HTTP/1.1 and earlier, are human-readable. In HTTP/2, these messages are embedded into a binary structure, a frame, allowing optimizations like compression of headers and multiplexing. Even if only part of the original HTTP message is sent in this version of HTTP, the semantics of each message is unchanged and the client reconstitutes (virtually) the original HTTP/1.1 request. It is therefore useful to comprehend HTTP/2 messages in the HTTP/1.1 format.
There are two types of HTTP messages, requests and responses, each with its own format.
An example HTTP request:
Requests consists of the following elements:
GET) or post the value of an HTML form (using POST), though more operations may be needed in other cases.http://), the {{Glossary("domain")}} (here, developer.mozilla.org), or the TCP {{Glossary("port")}} (here, 80).POST, similar to those in responses, which contain the resource sent.An example response:
Responses consist of the following elements:
The most commonly used API based on HTTP is the {{domxref("XMLHttpRequest")}} API, which can be used to exchange data between a {{Glossary("user agent")}} and a server. The modern {{domxref("Fetch API")}} provides the same features with a more powerful and flexible feature set.
Another API, server-sent events, is a one-way service that allows a server to send events to the client, using HTTP as a transport mechanism. Using the {{domxref("EventSource")}} interface, the client opens a connection and establishes event handlers. The client browser automatically converts the messages that arrive on the HTTP stream into appropriate {{domxref("Event")}} objects, delivering them to the event handlers that have been registered for the events' {{domxref("Event.type", "type")}} if known, or to the {{domxref("EventSource.onmessage", "onmessage")}} event handler if no type-specific event handler was established.
HTTP is an extensible protocol that is easy to use. The client-server structure, combined with the ability to simply add headers, allows HTTP to advance along with the extended capabilities of the Web.
Though HTTP/2 adds some complexity, by embedding HTTP messages in frames to improve performance, the basic structure of messages has stayed the same since HTTP/1.0. Session flow remains simple, allowing it to be investigated, and debugged with a simple HTTP message monitor.