A typical HTTP session
An HTTP session is a temporary information exchange between a server and a client. It is a sequence of network request-response transactions that are initiated by the client using TCP or an alternative protocol on a specific port. Typically, HTTP Sessions are created using port 80 or 8080. If a secure, encrypted session is created using HTTPS, then the default connection is made using port 443.
There are different versions of the Hypertext Transfer Protocol with the first major one being HTTP/1.1. The next major revision is HTTP/2, which was published as a standard in 2015. The next major revision is HTTP/3, which has not yet been officially adopted. However, the majority of web browsers already support it.
HTTP/2 is largely compatible with HTTP/1.1, with the high-level semantics left intact. The standard is primarily intended to decrease latency, leading to improved page loading speed in web browsers. One of the techniques applied is header Compression, which serves to shorten the transmission at the expense of additional processing cycles on each side of the transmission.
The semantics of the third major installment, HTTP/3, remain unchanged from the previous two versions of the protocol. However, the underlying transport protocol is no longer TCP, but QUIC. The change in protocol is intended to address the problem of “head-of-line blocking” that occurred in HTTP/2.
In this client-server protocol, there are three different stages. First, the connection is established using TCP or the QUIC protocol. Once the connection has been made, the client sends a HTTP request. In the final stage, the server processes the request and sends the appropriate data and a relevant status code back to the client.
For HTTP/1.0 and below, the HTTP Connection is dropped after the HTTP request is answered. In HTTP/1.1 and later, a keep-alive mechanism is used to improve performance for subsequent requests from the same client.
Step #1: Establishing a connection
The client establishes the HTTP Connection with the server using TCP or QUIC on one of the ports that the server is using to listen for HTTP connections.
By default, port 80 or 443 is used. The port can be specified as part of the URL, although it is assumed to be 80 if it is not included.
An HTTP session does not include provision for the server to send data to the client without an accompanying request. However, developers use different techniques to accomplish this. In HTTP/2, for example, the Server Push option allows the server to send more HTTP responses to the client before they are requested by the client. This is used in cases where the server knows in advance what the client will need to fully render the page, and thus does not have to wait for the request to arrive before sending the data.
Step #2: Sending the request
After the HTTP Connection is made, the client can send the HTTP request. Each HTTP request is a set of text instructions, each separated by a CRLF. There are several different request messages that the server expects, as follows:
The request line contains the HTTP request method, the HTTP request target, and the version of the protocol. Each component is separated by a space and the line is terminated with a CRLF.
For backward compatibility predating HTTP/1.0, a request line containing only that path is accepted by servers.
The HTTP protocol defines the set of HTTP request methods that can be used. They are GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, and PATCH. The behavior of a specific method is guided by the HTTP header fields that are included as part of the HTTP request.
Request header fields
A HTTP request header field is a specifier that guides the HTTP request method that is being executed. Each HTTP request header field includes a field name, followed by a colon and optional whitespace, and the field value followed by optional whitespace. Each HTTP request header field is terminated with a CRLF.
There are standard HTTP request fields such as Host, Date, and User-Agent, along with common non-standard HTTP request fields such as X-Forwarded-For to handle specialized tasks or provide client-specific or implementation-specific data. In HTTP/1.1, all of the HTTP header fields except for Host are optional.
An empty line is simply made up of a CRLF and contains no other whitespace. This is the line that separates the header block from the data block.
Message body (optional)
The message body contains data that is transmitted as part of the message, following the headers. A message body must be pre-declared using the HTTP Content-Length request header
HTTP GET / HTTP/1.1
This simple example fetches the root page from the specified URL. The final line is the empty line, indicating that the HTTP header field list is complete. Once the HTTP request is sent in its entirety, the server will process it and return the HTTP response.
HTTP PUT /customers/requests HTTP/1.1
“Name”: “David Smith”,
“Address”: “123 Bank Street”
This example HTTP PUT request is asking the server to accept the data as if it were formatted in JSON, and act accordingly. Upon receipt, the server might look up the customer using the specified ID and add the record if it does not exist. Alternatively, the name or address may be updated in the server-size database.
Step #3: Interpreting the response
An HTTP response is a specially-formatted answer that is returned by the server in response to a client request. It is formatted in a similar way to a HTTP request, containing several text blocks, each separated by a CRLF, but there are some important differences. Primarily, as one might expect, there are some distinct header fields that are indicative of a HTTP response.
As with HTTP request headers, there are both standard ones and non-standard ones that are commonly used. There are HTTP response headers in common with HTTP requests, such as Content-Type, but also HTTP response-specific headers like Last-Modified that contain information pertaining to the content being retrieved. This is information that the client does not necessarily know in advance.
The first line of the HTTP response indicates the HTTP version being used, followed by the HTTP status code, followed by a human-readable short description of the status. HTTP status codes are three digits long and are categorized by the first digit, with 2xx indicating a success.
HTTP/1.1 200 OK
Receiving this line at the top of the HTTP response indicates a successful request.
HTTP response headers
Each HTTP response header includes a field name, followed by a colon and options whitespace, and then the field value. HTTP response header fields include relevant data such as the data, type of content being returned if applicable, as well as content length. If the Content-Length field is missing then there is no message being returned.
Server: Apache/2.4.48 (Red Hat)
These two HTTP response headers indicate the name of the server and the language of the intended audience for the content being returned.
Message body (optional)
The message body is the data block that is optionally returned by the server. In cases where the HTTP request involves the retrieval of data, such as a web page, the content length will be specified in the corresponding HTTP response header.
Combining the example HTTP headers with a message body, a full HTTP response looks like:
Response indicating success
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
<p>This is a sample web page, used for testing.</p>
Response indicating a client error
HTTP/1.1 404 Not Found
Content-Type: text/html; charset=utf-8
<title>Page Not Found</title>
<p>The page you are looking for cannot be found.</p>
The typical HTTP session will involve a HTTP Connection between server and client using an established protocol that will differ based on the version of HTTP that is used. Messages consist of fields to specify actions, describe responses, transfer the relevant data, and indicate success, failure, or other information that is relevant to the HTTP request.