How HTTP Works — The Language of the Web

The TLS tunnel is established. Your browser has a secure, encrypted connection to Google’s server.

Now what?

Your browser knows it wants the /search page with q=hello. The server is listening for requests. But they need a shared language for how to ask and answer.

That language is HTTP.

GET /api/users/42 HTTP/1.1
Host: example.com

HTTP is just text

At its core, an HTTP/1.1 request is a plain text message. You could type one by hand using telnet:

GET /search?q=hello HTTP/1.1
Host: google.com
Accept: text/html

Hit enter twice (blank line signals end of headers), and the server sends back HTML. That’s literally all a browser does — thousands of times a day, automatically.

HTTP/2 and HTTP/3 serialize the same concepts differently (binary frames instead of text), but the structure — method, path, headers, body — is identical.

The request

Every HTTP request has the same structure:

METHOD /path HTTP/version
Header-Name: Header-Value
Header-Name: Header-Value

Body (optional)

Method — What kind of action you’re requesting. GET, POST, PUT, PATCH, DELETE are the most common.

Path — Which resource you want. /, /users/42, /api/search?q=hello. Everything after the domain name.

Headers — Metadata about the request. The browser’s identity, what response formats it accepts, authentication tokens, cookies.

Body — Data you’re sending to the server. Only used with POST, PUT, PATCH. Empty for GET and DELETE.

A real browser request looks like:

GET /search?q=hello HTTP/2
Host: google.com
User-Agent: Mozilla/5.0 Chrome/124.0
Accept: text/html,application/xhtml+xml,*/*
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, br
Cookie: NID=abc123; SID=xyz789
Cache-Control: no-cache

HTTP methods

The method tells the server what kind of operation you want. There are five you’ll use regularly:

GET — Retrieve a resource. Safe (no side effects), idempotent (same result every time). Never use GET to create or modify things. No body.

POST — Submit data to create something new. Not idempotent — clicking submit twice might create two records. Has a body.

PUT — Replace a resource entirely with what you’re sending. Idempotent — doing it twice gives the same result. Has a body.

PATCH — Partially update a resource. Change only the fields you send. Has a body.

DELETE — Remove a resource. Idempotent — deleting something twice is the same as deleting it once. No body.

The distinction between PUT and PATCH matters in practice:

PUT /users/42
{ "name": "Abhishek", "email": "a@b.com", "role": "admin" }
→ Replaces the entire user record. Fields you omit are cleared.

PATCH /users/42
{ "name": "Abhishek Saha" }
→ Updates only the name. Other fields untouched.

The response

Every HTTP response has:

HTTP/version STATUS-CODE Reason
Header-Name: Header-Value

Body

Status code — A three-digit number summarizing the result. The first digit is the category:

• 2xx — Success. 200 OK, 201 Created, 204 No Content
• 3xx — Redirect. 301 Moved Permanently, 302 Found, 304 Not Modified
• 4xx — Client error. The request was wrong. 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
• 5xx — Server error. The server failed. 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

The golden rule: 2xx means success, 4xx means you did something wrong, 5xx means the server did something wrong.

Returning 200 OK for a failed operation is one of the most common API design mistakes. If the user tries to access something they don’t have permission to, that’s a 403, not a 200 {"error": "forbidden"}.

Headers that actually matter

Request headers you’ll send often:

Response headers you’ll receive often:

The request-response cycle

Every HTTP interaction follows the same flow:

1. Client sends request — one complete message (method + path + headers + optional body)
2. Server processes — reads headers, runs logic, prepares answer
3. Server sends response — status code + headers + optional body
4. Connection is reused (HTTP/1.1 keep-alive, HTTP/2 multiplexing) or closed

This seems simple, but the request-response nature has an important implication: HTTP is always pull. The server can only respond, never initiate. If you want the server to push data to the client without being asked, you need a different protocol — WebSockets.

Statelessness

HTTP is stateless — each request is independent. The server doesn’t remember who you are between requests.

This is a deliberate design choice. Stateless servers can handle any request from any client, enabling horizontal scaling: add more servers, and any server can handle any request.

The tradeoff is that you have to re-identify yourself on every request. That’s what cookies and Authorization headers are for — they’re how you maintain “state” (like being logged in) across a stateless protocol.

The takeaway

HTTP is the vocabulary of the web. Every API call, every page load, every image fetch is an HTTP request. Understanding what method to use, what status code to return, and what headers to set makes you a more effective developer on both sides of the wire.

The actual bytes that travel are simple. The conventions around them — REST, status codes, caching — are what decades of web development has built on top.

Next up: HTTP/1.1 can only send one request at a time on each connection. A modern page needs dozens of files. HTTP/2 changes this completely. How HTTP/2 Works →