Recess
Sign in
← Back to feed
You're reading as a guest. Sign in to save posts, see what's new, and tune your feed.
Sign in
WEB DEVELOPMENT · ESSAY · 5 MIN · INTERMEDIATE

What is HTTP, really?

Every web page you load is a polite letter and a polite reply, sent in plain text over a socket.

Type example.com into a browser and your machine opens a TCP connection to a server on port 80 (or 443 for HTTPS), then sends a few lines of plain text. That text is the request. The server reads it, decides what to do, and sends back another block of text: the response. That handshake — request, response, close — is the entire protocol. HTTP, the HyperText Transfer Protocol, was first sketched by Tim Berners-Lee at CERN in 1989 and standardized as HTTP/1.0 in 1996. The shape has changed since (HTTP/2 in 2015, HTTP/3 over QUIC in 2022) but the conversation has not.

A request has a verb, a path, a version, and a list of headers. GET /index.html HTTP/1.1 says "send me this resource." POST /login says "here is data, do something with it." PUT, DELETE, PATCH, HEAD, and OPTIONS round out the standard set. After the verb-line, the client lists key-value headers — Host: example.com, User-Agent: Mozilla/5.0, Accept: text/html — then a blank line, then optionally a body. The blank line is load-bearing: it tells the server "headers end here, body starts now."

The response mirrors the shape. First line: HTTP/1.1 200 OK. Then headers — Content-Type: text/html, Content-Length: 1234, Set-Cookie: session=abc123. Then a blank line. Then the body. The status code on that first line is the server's one-word verdict. 2xx means it worked, 3xx means "go somewhere else," 4xx means you (the client) made a mistake, 5xx means the server did. 404 is famous; 301 quietly powers every site migration; 429 is what you see when you've hit a rate limit; 503 means the server is up but refusing to answer right now. The categories matter more than the specific numbers, because intermediaries — proxies, CDNs, browsers — make decisions based on the leading digit.

Headers are where the protocol gets interesting. They're how a browser tells a server what languages it speaks (Accept-Language: en-US), how a server tells a browser to cache a response for an hour (Cache-Control: max-age=3600), how authentication tokens travel (Authorization: Bearer ...), and how cookies persist a session across stateless requests (Cookie: session=abc123). HTTP itself is stateless — each request stands alone, the server forgets you the moment it answers — and cookies were invented in 1994 at Netscape specifically to paper over that statelessness. Without them, every page load would be a stranger meeting a stranger.

The S in HTTPS is TLS, Transport Layer Security, wrapped around the same plaintext conversation. When you connect to https://example.com, the first thing that happens is a TLS handshake: the server presents a certificate signed by a Certificate Authority your browser already trusts, the two sides agree on a session key using elliptic-curve Diffie-Hellman, and from that point on every byte — request line, headers, body, response — is encrypted end to end. An attacker on the same Wi-Fi can see that you connected to example.com (the hostname leaks via SNI) but not what you asked for or what came back. Before HTTPS was the default, login forms over public Wi-Fi were trivially sniffable; the Firesheep extension in 2010 made that uncomfortably visible and the industry's slow shift to HTTPS-everywhere followed. Today roughly 95% of pages loaded in Chrome are over HTTPS.

HTTP/2 changed the wire format without changing the semantics. Instead of one request per TCP connection (HTTP/1.1's six-connections-per-host workaround for the head-of-line problem), HTTP/2 multiplexes many requests over one binary, framed connection. Headers get compressed with HPACK. The verbs, status codes, and headers a developer sees are identical. HTTP/3 goes further: it abandons TCP entirely for QUIC, a UDP-based transport with built-in encryption and faster connection setup, especially on flaky mobile networks. Again, the application-layer model — verb, path, headers, body, status — does not change.

This is the trick worth holding onto. Frameworks come and go, REST and GraphQL argue about resource shape, WebSockets and Server-Sent Events extend the model — but underneath, almost every byte your computer exchanges with the public internet is a HTTP request and a HTTP response. Open the Network tab in your browser's devtools and you can read them, line by line, the same plain text Berners-Lee was sending in 1990.

#http#web#networking#protocols#https
Sources
MDN Web DocsIETFIETF