Skip to content

How HTTP Works

HTTP (HyperText Transfer Protocol) is the request/response protocol that powers the web. Every time a browser loads a page, or one service calls another over REST, it's speaking HTTP underneath.

The basic model

HTTP is a client-server, request/response protocol:

  1. A client (browser, curl, another service) opens a connection and sends a request.
  2. The server processes it and sends back a response.
  3. By default, the connection can be reused for further requests (HTTP/1.1 keep-alive), but each request/response pair is logically independent — HTTP itself is stateless.

Anatomy of a request

GET /api/users/42 HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer <token>
  • Method — what you want to do (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS)
  • Path — the resource you're targeting
  • Headers — metadata: content type, auth, caching hints, etc.
  • Body — optional payload, used with POST/PUT/PATCH

Anatomy of a response

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 58

{"id": 42, "name": "Chetan"}
  • Status line — protocol version + status code
  • Headers — content type/length, caching, cookies, etc.
  • Body — the actual payload (or empty, e.g. for 204 No Content)

Status code ranges

Range Meaning Examples
1xx Informational 101 Switching Protocols
2xx Success 200 OK, 201 Created, 204 No Content
3xx Redirection 301 Moved Permanently, 304 Not Modified
4xx Client error 400 Bad Request, 401 Unauthorized, 404 Not Found
5xx Server error 500 Internal Server Error, 503 Service Unavailable

Statelessness and how sessions work around it

HTTP itself has no memory of previous requests. Anything that looks like a "session" — a logged-in user, a shopping cart — is layered on top, usually via:

  • Cookies, sent by the server (Set-Cookie) and echoed back by the client on every subsequent request
  • Tokens (JWTs, bearer tokens) sent in an Authorization header, validated server-side per request

HTTP/1.1 vs HTTP/2 vs HTTP/3

  • HTTP/1.1 — text-based, one request per TCP connection at a time unless pipelined (rarely used); keep-alive reuses the connection
  • HTTP/2 — binary framing, multiplexes many requests over a single TCP connection, header compression
  • HTTP/3 — runs over QUIC (UDP-based) instead of TCP, avoiding TCP head-of-line blocking and cutting connection setup latency

Trying it yourself

curl -v https://example.com

The -v flag prints the full request and response, headers included — the fastest way to actually see what's described above.