Hypertext Transfer Protocol

Hypertext Transfer Protocol (HTTP) is an application OSI layer communication protocol.

Overview

The actors involved in an HTTP communication are a client and a server.

Types of messages in HTTP:

Request
Response

Flow

Standard HTTP flow:

Client opens Transport layer connection (TCP or QUIC)
Client sends an HTTP message
Client reads the response by the server
Client closes or reuses the connection for further requests

Server-sent events (SSE) is a standard that allows a server to send messages to a client.

Client sends a message to the server
The server sends events to the client

Request

An HTTP request is a message sent from a client to a server.

It is composed of:

Request method
Path
Protocol version
Headers
Body

There are different request methods. They are listed below.

The path uses default values. In case it is all default, the content is just the symbol /.

In RESTful, the path identifies a resource, usually a noun.

A protocol version example is HTTP/1.1

Body is optional, and it used in requests only for some request methods like POST.

Response

An HTTP response is a message from a server to a client as a response.

It is composed of:

Protocol version
Status code
Status message
Headers
Body

Body is optional, and it is used in responses only for some requests methods like GET.

Protocol versions

HTTP/1.0
HTTP/1.1
HTTP/2
HTTP/3

HTTP/1.0 was the original implementation. It is text-based, i.e. human-readable.

HTTP/1.1 is text-based, i.e. human-readable. It introduced pipelining (which proved difficult to implement) and persistent connections: the underlying TCP connection can be partially controlled using the Connection header.

As of 2026, HTTP/1.1 can be considered the most universal version of HTTP.

Pipelining means that multiple messages can be sent without waiting for the first response to be fully received. As it was considered difficult to be implemented in practice due to coexistence of old and new software, it was superseded by HTTP/2 multiplexing.

HTTP/2 is binary-based. It multiplexes messages over a single connection, helping keep the connection warm and more efficient.

The frame is the binary structure used in HTTP/2 to embed the request.

HTTP/2 keeps the semantics of each message unchanged and the client reconstitutes (virtually) the original text-based HTTP/1.1 format.

HTTP/3 is binary-based and uses QUIC (over UDP) rather than TCP.

HTTP Request Methods

HTTP request methods:

GET
HEAD
POST
PUT
DELETE
CONNECT
OPTIONS
TRACE
PATCH

HTTP Status Code

There are different HTTP status code defined in the standard.

HTTP status code classes:

1xx informational response – the request was received, continuing process
2xx successful – the request was successfully received, understood, and accepted
3xx redirection – further action needs to be taken in order to complete the request
4xx client error – the request contains bad syntax or cannot be fulfilled
5xx server error – the server failed to fulfil an apparently valid request

Popular HTTP status codes:

200 means that everything was correct.

403 means forbidden.

404 means page not found.

500 means a generic internal server error.

You can find a complete list of HTTP status codes on this external link.

HTTP Cookies

HTTP is a stateless protocol, so it does not save what is done in previous sessions.

Cookies is a technique that allows to keep information between sessions.

When Secure cookie is set, only cookes sent via HTTPS TLS or SSL sessions are allowed. This prevents man-in-the-middle (MitM) attacks that target cookies.

Cookies are vulnerable to DNS spoofing.

Domain cookies should usually have the narrowest possible scope, which is actually accomplished by not setting the domain cookie. This allows only the originating server to access the cookie.

Cookies without the Expires or Max-age attributes are ephemeral an dwill only be kept for the session, making them less vulnerable than stored cookies.

The HTTPOnly attribute is a good idea, but it prevents scripting rather than requiring unencrypted HTTP sessions.

HTTP/2 over TLS

According to the standard RFC 7540, the HTTP/2 over TLS should use TLS 1.2 or above.

HTTP Tunneling

You can read a post about HTTP tunneling tools.

HTTP Security

SSL protocols were declared unsafe and it was substituted by TLS. There are TLS versions, and not all of them are safe, so they should be updated as well.

You can read this post about how to update TLS 1.0.

TLS basic stages:

Algorithm negotiation
Authentication key exchange
Symmetric key ciphering

You can read this post about HTTP traffic capture tools.

Input

HTTP offers multiple data inputs that are reviewed on this section:

Path parameters
Query parameters
Body

Path parameters are usually used for identity-related (domain entities or aggregates) and hierarchical data. It can follow the entity-value order. Example: /saves/{save-id}/teams/{team-id}/.

Query parameters (with the format ?field=value&) are used for optional data to narrow or shape the response. They are optional, and the order doesn’t matter.

The body is used for no-identification data. An example is the payload with data to be updated.

Frameworks

Fetch API is the most common API for a JavaScript client.

FastAPI is an HTTP framework for a Python server.

Bibliography

“Overview of HTTP“. Mozilla Developer Network (MDN)