HTTP Explained

HTTP (Hypertext Transfer Protocol) is a stateless, application-level request-response protocol for distributed hypertext information systems. The semantics are shared across all HTTP versions. Clients send requests to servers, servers return responses, and intermediaries like proxies and CDNs relay messages between them. HTTP operates over TCP (versions 1.0 and 1.1), over TCP with multiplexed streams (HTTP/2), or over QUIC (HTTP/3).

Usage

HTTP is the protocol behind nearly all communication on the web. A browser loading a page sends an HTTP request for the HTML document, parses the response, then sends additional requests for stylesheets, scripts, images, fonts, and other subresources. APIs, mobile applications, IoT devices, and search engine crawlers all use HTTP as their transport protocol.

The protocol operates on a simple exchange: a client sends a request describing an action on a resource, and the server returns a response with the outcome. The resource is identified by a URL and the action is specified by an HTTP method. This uniform interface keeps the protocol independent of resource types. The same protocol transfers HTML, JSON, binary files, video streams, and any other content.

Message format

An HTTP message has three parts:

Start line: a request line (for requests) or a status line (for responses)
Header fields: zero or more name-value pairs providing metadata about the message
Message body: optional content carrying the resource data or request data

A blank line (CRLF) separates the header fields from the body. The start line and headers are plain text. The body carries the actual resource data and is often compressed.

Request message

A request message begins with a request line containing three elements separated by spaces: the method, the request target (the path and query of the resource), and the HTTP version.

GET /api/products?page=2 HTTP/1.1
Host: www.example.re
Accept: application/json
Accept-Encoding: gzip

The method (GET) indicates the desired action. The request target (/api/products?page=2) identifies the resource. The version (HTTP/1.1) declares the message syntax.

Headers follow the request line. The Host header is the only required header in HTTP/1.1. Other common request headers include Accept, Accept-Encoding, Authorization, Cookie, and User-Agent.

A request body is present when the method carries content, such as POST or PUT. GET requests typically have no body.

Response message

A response message begins with a status line containing the HTTP version, a three-digit status code, and an optional reason phrase.

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 245
Cache-Control: max-age=60

{"products":[...]}

The status code (200) conveys the outcome. The reason phrase (OK) is a human label with no protocol significance. HTTP/2 and HTTP/3 omit the reason phrase entirely.

Common response headers include Content-Type, Content-Length, Cache-Control, Set-Cookie, and ETag.

Statelessness

HTTP is stateless by design. Each request is self-contained. The server does not retain any memory of previous requests from the same client. This property allows HTTP to scale horizontally: any server behind a load balancer handles any request without needing shared session state.

State persistence happens at a higher layer. Cookies carry session identifiers between requests. Tokens in the Authorization header authenticate individual requests. The protocol itself treats every exchange as independent.

Methods

The method in the request line tells the server what action to perform on the target resource. HTTP defines the following methods.

Method	Purpose
GET	Retrieve a resource
HEAD	Retrieve headers only (no body)
POST	Submit data for processing
PUT	Replace a resource
DELETE	Remove a resource
PATCH	Partially modify a resource
OPTIONS	Query server capabilities
CONNECT	Establish a tunnel
TRACE	Loop-back test

Methods are classified by two properties. Safe methods (GET, HEAD, OPTIONS, TRACE) do not modify server state. Idempotent methods (all safe methods plus PUT and DELETE) produce the same result regardless of how many times the request is repeated.

Status codes

The status code in the response indicates the outcome of the request. Status codes are grouped into five classes by their first digit:

Class	Range	Meaning
1xx	100–199	Informational, request received, processing continues
2xx	200–299	Success, request accepted and processed
3xx	300–399	Redirection, further action needed
4xx	400–499	Client error, malformed or unauthorized request
5xx	500–599	Server error, valid request, server failed

The most common status codes: 200 (success), 301 (permanent redirect), 304 (not modified), 404 (not found), and 500 (server error).

Headers

HTTP headers are name-value pairs carrying metadata about the request, the response, or the message body. Headers control Caching, Authentication, Compression, content negotiation, connection behavior, and security policy.

Headers fall into several categories:

Request headers: preferences and context sent by the client (Accept, User-Agent, Authorization)
Response headers: server metadata and instructions (Cache-Control, Set-Cookie, Content-Type)
Representation headers: describe the body content (Content-Encoding, Content-Language)

Header field names are case-insensitive. Multiple headers with the same name are valid when the header specification permits a list of values.

HTTP versions

HTTP has gone through several versions, each addressing performance and security limitations of the previous one.

HTTP/0.9

HTTP/0.9 (1991) was a one-line protocol. The client sent a single GET request line with no headers. The server returned raw HTML and closed the connection. No status codes, no headers, no content types.

HTTP/1.0

HTTP/1.0 (1996) added headers, status codes, and support for content types beyond HTML. Each request opened a new TCP connection and closed the connection after the response. The overhead of repeated TCP handshakes made pages with many subresources slow to load.

HTTP/1.1

HTTP/1.1 (1999) made persistent connections the default. A single TCP connection carries multiple request-response exchanges without reconnecting. Pipelining allowed sending multiple requests without waiting for responses, though head-of-line blocking at the TCP layer limited the practical benefit. Chunked transfer encoding enabled Streaming responses of unknown length.

HTTP/2

HTTP/2 (2015) introduced binary framing and multiplexing. Multiple requests and responses flow concurrently over a single TCP connection as interleaved frames. Header Compression (HPACK) reduces overhead from repetitive headers. Server push allows the server to send resources before the client requests them.

HTTP/3

HTTP/3 (2022) replaces TCP with QUIC, a UDP-based transport with built-in encryption. QUIC eliminates TCP head-of-line blocking. A lost packet on one stream does not stall other streams. The initial handshake combines transport and TLS setup in a single round trip. Connection migration allows clients to switch networks (Wi-Fi to cellular) without re-establishing the connection.

Connection lifecycle

Loading a web page involves several protocol layers working in sequence:

DNS resolution: the browser resolves the hostname to an IP address
TCP handshake: a three-way handshake (SYN, SYN-ACK, ACK) establishes the transport connection (one round trip)
TLS handshake: for HTTPS, the client and server negotiate encryption parameters and verify the server certificate (one additional round trip with TLS 1.3)
HTTP request: the client sends the request message over the established connection
Server processing: the server processes the request and generates a response
HTTP response: the server sends the response message back to the client
Connection reuse or close: persistent connections in HTTP/1.1 and multiplexed connections in HTTP/2 keep the connection open for subsequent requests

With HTTP/3 and QUIC, steps 2 and 3 merge into a single round trip, reducing latency for new connections.

Connection reuse matters

Each new TCP connection adds at least one round trip of latency. For a server 100 ms away, the TCP handshake alone costs 100 ms. Adding TLS doubles the cost. Persistent and multiplexed connections amortize this overhead across many requests.

Intermediaries

Intermediaries sit between the client and the origin server. Messages pass through one or more intermediaries before reaching the destination.

Forward proxy: acts on behalf of the client, often used for filtering, logging, or Caching within a corporate network
Reverse proxy: sits in front of the origin server, handling load balancing, TLS termination, and Caching
CDN: a geographically distributed network of reverse proxy caches serving content from edge locations close to the client

Intermediaries operate at the HTTP layer (application level). Lower-level devices like routers and firewalls forward packets without inspecting HTTP messages.

The Via header records intermediaries in the request and response chain. Each proxy appends an entry identifying the protocol version and the proxy hostname.

Security

Plain HTTP transmits messages in cleartext. Any device on the network path reads or modifies the content in transit. HTTPS layers HTTP over TLS, encrypting the entire HTTP exchange including the URL path, Headers, and body.

HTTPS provides three guarantees:

Confidentiality: the message content is encrypted
Integrity: tampering is detected
Authentication: the server proves its identity through a certificate chain

HSTS instructs browsers to use HTTPS for all future connections to a host, preventing protocol downgrade attacks.

Modern browsers mark plain HTTP pages as insecure. Features like service workers, geolocation, and the Web Crypto API require a secure context (HTTPS).

Example

A browser navigates to https://www.example.re/about. After DNS resolution, TCP handshake, and TLS handshake, the browser sends an HTTP request.

Request

GET /about HTTP/1.1
Host: www.example.re
Accept: text/html
Accept-Encoding: gzip, br
Accept-Language: en-US
Cookie: session=abc123

Response

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Encoding: br
Content-Length: 4820
Cache-Control: max-age=300
ETag: "about-v7"
Strict-Transport-Security: max-age=31536000
Vary: Accept-Encoding

(compressed HTML body)

The 200 status confirms success. The Content-Type header declares the body as HTML. The Cache-Control header allows caching for five minutes. The ETag provides a validator for future conditional requests. The Strict-Transport-Security header enforces HTTPS for one year.

SEO impact

Search engine crawlers are HTTP clients. Googlebot follows the same protocol rules as browsers, resolving DNS, establishing connections, sending requests, and processing responses. Proper status codes, Cache-Control headers, Redirects, and structured response headers directly affect how efficiently a site is crawled and indexed.

Takeaway

HTTP is a stateless request-response protocol forming the foundation of the web. Clients send requests with a method, target URL, and Headers. Servers return responses with a status code, headers, and an optional body. The protocol has progressed from single-request connections in HTTP/0.9 to multiplexed, encrypted streams in HTTP/3, but the core request-response model remains unchanged.