web

How HTTP Actually Works — Methods, Status Codes, and Headers Explained

Open a browser tab, type abcsteps.com, hit Enter. In the half-second before the page appears, your computer and ours had a precise conversation. Your browser...

DS
Divyanshu Singh Chouhan
8 min read1,504 words

The Conversation That Powers Every Click

Open a browser tab, type abcsteps.com, hit Enter. In the half-second before the page appears, your computer and ours had a precise conversation. Your browser said something. Our server said something back. The structure of that exchange is HTTP — the Hypertext Transfer Protocol — and it has not changed in spirit since 1991.

Understanding HTTP is not optional for an engineer. Almost every system you will build either speaks HTTP or wraps something that does. APIs, websites, mobile apps talking to backends, servers calling other servers, even your IDE checking for updates — all HTTP. Once the protocol is in your head, a thousand things stop being mysterious.

This article is the mental model. Methods, status codes, headers, and the request-response shape — what they actually mean, not the specification's wording.

The Shape of a Request

An HTTP request is a small text document. Here is one your browser sends when you ask for the homepage:

GET /index.html HTTP/1.1
Host: abcsteps.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 14_3)
Accept: text/html
Accept-Language: en-US
Connection: keep-alive

Five things are happening:

  • Method (GET) — what action you want.
  • Path (/index.html) — what resource you want.
  • Version (HTTP/1.1) — which dialect of the protocol.
  • Headers (the lines after the first) — metadata about the request.
  • Body (empty here, follows a blank line) — the payload, when you have one.

That is the whole structure. Everything else is variations on this shape.

Methods — The Verbs

HTTP defines a small fixed set of methods. The four you will use almost every day:

MethodMeansBody?Idempotent?
GETRead a resourceNoYes
POSTCreate a resource (or trigger an action)YesNo
PUTReplace a resourceYesYes
DELETERemove a resourceOptionalYes

The two side-properties matter:

  • Body says whether the method is allowed to carry a payload. GET is not — if you need to send data, you put it in the URL or you change methods.
  • Idempotent means "calling it twice has the same effect as calling it once." GET is idempotent (reading the homepage twice does not change anything). POST is not (sending the same payment twice charges you twice).

Two more you will see:

  • PATCH — like PUT but for partial updates ("change just this one field").
  • OPTIONS — "what methods does this URL accept?" — used by browsers for CORS preflight checks before risky cross-origin requests.

That is the whole set. There are a few more in the specification (HEAD, TRACE, CONNECT), but you can build a career and rarely touch them.

Status Codes — The Three-Digit Reply

The server's response begins with a status code: a three-digit number that tells you, in one glance, whether the request worked. The first digit groups the meaning:

RangeMeaningCommon ones
1xxInformational100 Continue (rare)
2xxSuccess200 OK, 201 Created, 204 No Content
3xxRedirection301 Moved Permanently, 302 Found, 304 Not Modified
4xxClient error (you)400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
5xxServer error (us)500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout

Two distinctions worth burning in:

  • 401 vs 403. 401 means "I don't know who you are" — log in. 403 means "I know who you are and you are not allowed" — no login can fix this. Mixing them up is a common bug; the right code helps clients build the right UI.
  • 404 vs 410. 404 means "I have no record of this." 410 means "I had a record of this and it is gone — stop asking." Search engines treat them differently; 410 removes a URL from the index faster.

Knowing the right code is half of being good at HTTP. The wrong code makes correct clients behave incorrectly.

Headers — The Metadata Channel

Headers are how requests and responses carry information that does not belong in the URL or the body. A real response looks something like this:

HTTP/1.1 200 OK
Date: Wed, 29 Apr 2026 14:30:00 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 12453
Cache-Control: public, max-age=3600
ETag: "9f2a3d-4e1"
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict

A few headers you will see again and again:

  • Content-Type — what kind of bytes follow the blank line. text/html, application/json, image/png, etc. Without it, the receiver guesses, and guessing badly is a common source of weird bugs.
  • Content-Length — how many bytes the body has. Lets the receiver know when the message ends.
  • Authorization — credentials. Usually Bearer <token> for APIs.
  • Accept — "I'd like the response in this format." A client can say Accept: application/json and a polite server will oblige.
  • Cache-Control — caching rules. no-store = "do not cache." public, max-age=3600 = "anyone can cache for an hour."
  • ETag / If-None-Match — version tags. The browser asks "still the same as "9f2a3d-4e1"?" and the server can reply 304 Not Modified instead of resending the whole resource. This is half of why the web feels fast.
  • Set-Cookie / Cookie — the round-trip mechanism for sessions. The server sets a cookie; the browser sends it back on every subsequent request to the same origin.

You will end up reading headers in the browser DevTools Network tab more than anywhere else. It is worth learning the panel.

A Full Round-Trip

Concretely, when you click a "Like" button on a website, this happens:

Request:
POST /api/posts/42/likes HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGc...
Content-Type: application/json
Content-Length: 17

{"userId": 1234}

Response:
HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/posts/42/likes/9876
Content-Length: 28

{"id": 9876, "likes": 145}

Reading top-to-bottom: the client POSTs a JSON payload to a specific URL with a bearer token. The server replies 201 Created, tells the client where the new resource lives via the Location header, and includes the result in the body. Every modern API works this way.

HTTP/1.1, HTTP/2, HTTP/3 — Same Conversation, Faster Pipes

You will see version numbers everywhere. Worth knowing what they mean:

  • HTTP/1.1 (1997) — the version everything understands. Plain-text on the wire. One request per connection, kept alive between requests so the connection itself can be reused.
  • HTTP/2 (2015) — same semantics, binary framing, and multiplexing — many requests share one connection and can interleave. This is why modern sites with dozens of small assets feel fast even on slow connections.
  • HTTP/3 (2022) — same semantics again, runs over QUIC (a UDP-based transport) instead of TCP. Survives network changes (Wi-Fi → cellular) without dropping the connection. Cloudflare and Google have rolled it out widely.

The methods, status codes, and headers are identical across all three. You can write code against HTTP without thinking about which version is on the wire.

HTTPS Is HTTP With a Lock

https:// is the same protocol with one addition: the connection is wrapped in TLS (Transport Layer Security). The bytes are encrypted between your browser and the server. Anyone in the middle — your ISP, a coffee-shop Wi-Fi, a hostile network — sees only ciphertext.

Modern browsers refuse to load mixed content (an https:// page including http:// resources) and warn loudly on plain-HTTP forms. There is no good reason in 2026 to run a public site over plain HTTP. Free certificates from Let's Encrypt and one-line setup on Cloudflare have removed the last excuses.

The Stateless Truth

One last thing — and this is the property that surprises new engineers more than any other: HTTP is stateless. Each request is independent. The server, by default, has no memory of you between requests.

Sessions, login, "stay signed in" — all of those exist because we built memory on top of stateless HTTP. The server gives the browser a cookie. The browser sends the cookie back on every subsequent request. The server uses the cookie to look up your session in a database. The protocol stays stateless; the application has memory.

This is why scaling matters. A stateless protocol means a load balancer can send your second request to a completely different server than your first, and as long as both servers can read the same session store, you do not notice.

Where This Fits

In the ABCsteps curriculum, lesson 09 has you call real APIs — sending requests, reading responses, handling errors. Without the mental model in this article, status codes look like random numbers and headers look like noise. With it, every API call is just a polite version of the conversation you now know how to read.

The lesson gives you the keystrokes. This article gives you the language they are speaking.

09

Apply this hands-on · Module B

How Apps Talk: APIs Revealed

Lesson 09 calls real APIs. HTTP is the language the calls speak. This article makes status codes and headers concrete before the lesson hands you the keyboard.

Open lesson

#http #networking #protocols #fundamentals
DS

Divyanshu Singh Chouhan

Founder, ABCsteps Technologies

Founder of ABCsteps Technologies. Building a 20-lesson AI engineering course that teaches AI, ML, cloud, and full-stack development through written lessons and real projects.