Editing HTTP (section)

== HTTP data exchange ==
HTTP is a [[stateless protocol|stateless]] application-level protocol and it requires a reliable network transport connection to exchange data between client and server.<ref name="rfc9110-3.3">{{cite IETF |rfc=9110 |section=3.3 |sectionname=Connections, Clients, and Servers |title=RFC 9110, HTTP Semantics}}</ref> In HTTP implementations, [[Transmission Control Protocol|TCP/IP]] connections are used using [[List_of_TCP_and_UDP_port_numbers#Well-known_ports|well-known ports]] (typically [[TCP port|port 80]] if the connection is unencrypted or port 443 if the connection is encrypted, see also [[List of TCP and UDP port numbers]]).<ref name="rfc9110-4.2.1">{{cite IETF |rfc=9110 |sectionname=http URI Scheme |section=4.2.1 |title=RFC 9110, HTTP Semantics}}</ref><ref name="rfc9110-4.2.2">{{cite IETF |rfc=9110 |sectionname=https URI Scheme |section=4.2.2 |title=RFC 9110, HTTP Semantics}}</ref> In HTTP/2, a TCP/IP connection plus multiple protocol channels are used. In HTTP/3, the application transport protocol [[QUIC]] over UDP is used.

=== Request and response messages through connections ===
Data is exchanged through a sequence of [[Request-response|request–response messages]] which are exchanged by a [[session layer]] transport connection.<ref name="rfc9110-3.3" /> An HTTP client initially tries to connect to a server establishing a connection (real or virtual). An HTTP(S) server listening on that port accepts the connection and then waits for a client's request message. The client sends its HTTP request message. Upon receiving the request the server sends back an HTTP response message, which includes header(s) plus a body if it is required. The body of this response message is typically the requested resource, although an error message or other information may also be returned. At any time (for many reasons) client or server can close the connection. Closing a connection is usually advertised in advance by using one or more HTTP headers in the last request/response message sent to server or client.<ref name="rfc9112-9.1">{{cite IETF |rfc=9112 |sectionname=Connection Management: Establishment |section=9.1 |title=RFC 9112, HTTP/1.1}}</ref>

=== Persistent connections ===
{{Main|HTTP persistent connection}}
In '''HTTP/0.9''', the TCP/IP connection is always closed after server response has been sent, so it is never persistent.

In '''HTTP/1.0''', as stated in RFC 1945, the TCP/IP connection should always be closed by server after a response has been sent.{{refn|group=note|Since late 1996, some developers of popular HTTP/1.0 browsers and servers (specially those who had planned support for HTTP/1.1 too), started to deploy (as an unofficial extension) a sort of keep-alive-mechanism (by using new HTTP headers) in order to keep the TCP/IP connection open for more than a request/response pair and so to speed up the exchange of multiple requests/responses.<ref name="HTTP-Persistent-Connections">{{Cite book|url=https://www.oreilly.com/library/view/http-the-definitive/1565925092/ch04s05.html|title=HTTP: The Definitive Guide. (excerpt of chapter: "Persistent Connections")|author1=David Gourley|author2=Brian Totty|author3=Marjorie Sayer|author4=Anshu Aggarwal|author5=Sailu Reddy|language=en|publisher=O'Reilly Media, inc.|isbn=9781565925090|year=2002|access-date=2021-10-18}}</ref>}}

In '''HTTP/1.1''' a keep-alive-mechanism was officially introduced so that a connection could be reused for more than one request/response. Such persistent connections reduce request [[Network latency|latency]] perceptibly because the client does not need to re-negotiate the [[Transmission Control Protocol#Connection establishment|TCP 3-Way-Handshake connection]] after the first request has been sent. Another positive side effect is that, in general, the connection becomes faster with time due to TCP's [[TCP congestion control#Slow start|slow-start]]-mechanism.

'''HTTP/1.1''' added also [[HTTP pipelining]] in order to further reduce lag time when using persistent connections by allowing clients to send multiple requests before waiting for each response.  This optimization was never considered really safe because a few web servers and many [[proxy server]]s, specially transparent proxy servers placed in Internet / [[Intranet]]s between clients and servers, did not handle pipelined requests properly (they served only the first request discarding the others, they closed the connection because they saw more data after the first request or some proxies even returned responses out of order etc.).  Because of this, only HEAD and some GET requests (i.e. limited to real file requests and so with [[URL]]s without query string used as a command, etc.) could be pipelined in a [[#Safe methods|safe]] and [[#Idempotent methods|idempotent]] mode.  After many years of struggling with the problems introduced by enabling pipelining, this feature was first disabled and then removed from most browsers also because of the announced adoption of HTTP/2.

'''HTTP/2''' extended the usage of persistent connections by multiplexing many concurrent requests/responses through a single TCP/IP connection.

'''HTTP/3''' does not use TCP/IP connections but QUIC + UDP (see also: [[#Technical overview|technical overview]]).

=== Content retrieval optimizations ===
; HTTP/0.9
: A requested resource was always sent in its entirety.
; HTTP/1.0
: HTTP/1.0 added headers to manage resources cached by client in order to allow conditional GET requests; in practice a server has to return the entire content of the requested resource only if its last modified time is not known by client or if it changed since last full response to GET request. One of these headers, "Content-Encoding", was added to specify whether the returned content of a resource was or was not [[HTTP compression|compressed]].
: If the total length of the content of a resource was not known in advance (i.e. because it was dynamically generated, etc.) then the header <code>"Content-Length: number"</code> was not present in HTTP headers and the client assumed that when server closed the connection, the content had been sent in its entirety.  This mechanism could not distinguish between a resource transfer successfully completed and an interrupted one (because of a server / network error or something else).
; HTTP/1.1
: HTTP/1.1 introduced:
:* new headers to better manage the conditional retrieval of cached resources.
:* [[chunked transfer encoding]] to allow content to be streamed in chunks in order to reliably send it even when the server does not know its length in advance (i.e. because it is dynamically generated, etc.).
:* [[Byte serving|byte range serving]], where a client can request only one or more portions (ranges of bytes) of a resource (i.e. the first part, a part in the middle or in the end of the entire content, etc.) and the server usually sends only the requested part(s).  This is useful to resume an interrupted download (when a file is very large), when only a part of a content has to be shown or dynamically added to the already visible part by a browser (i.e. only the first or the following n comments of a web page) in order to spare time, bandwidth and system resources, etc.
; HTTP/2, HTTP/3
: Both HTTP/2 and HTTP/3 have kept the above mentioned features of HTTP/1.1.