The Understory
Day 319 min read🧱 The Web Platform

The Language of the Web

You type readunderstory.ink into your browser. You hit enter. Half a second later, a page appears. Somewhere in that half-second, your browser sent a small text message to a server, and the server sent one back. Those messages have a name. They have a structure. And once you learn to read them, you’ll never look at the web the same way again.

That message format is called HTTP. It’s the language of the web. And today, we’re going to learn to speak it — and read it — properly.

Not a program — a language

First, the most important thing to clear up: HTTP is not software. It’s not something you install. It’s a protocol — a set of rules for how two computers should talk.

HTTP stands for HyperText Transfer Protocol. Every word matters:

HTTP — HyperText Transfer Protocol: the application-layer protocol that defines how clients and servers exchange messages on the web, including the shape of a request, the shape of a response, and the meaning of the methods and status codes inside them.

In plain terms: “The agreed grammar for asking and answering. Not a program — a language.”

  • HyperText — text that links to other text. The “hyper” refers to the links that let you jump from one document to another. That was the original revolutionary idea of the web.
  • Transfer — it moves things from one place to another.
  • Protocol — an agreed-upon set of rules. Like diplomatic protocol at a state dinner. Everyone knows how to behave.

Analogy: HTTP is like a formal letter-writing convention. If we both agree to write letters with a date at the top, a recipient below that, a greeting, a body, and a signature — we can communicate even if we’ve never met. HTTP is that convention, but for computers, and about a thousand times faster.

HTTP is text (mostly)

Here’s the beautiful truth: HTTP messages are readable text. You can literally watch them being exchanged. You can write one by hand. You can read one in your browser’s DevTools.

Before HTTPS became standard, you could open a network tool and see every word being said. Now with HTTPS, everything’s encrypted — but conceptually, the messages are still simple text underneath.

Analogy: Think of HTTP as writing letters in plain English. Anyone who intercepts the letter can read it. HTTPS is writing the same letters in a secret code that only you and the recipient can unlock. The format of the letter is still the same — the contents are scrambled.

We’ll get to HTTPS properly in a bit. First, let’s learn the language itself.

The anatomy of a request

Request — A message sent by a client asking a server to perform an action or return a resource, containing a method, a target, headers, and optionally a body.

In plain terms: “The question.”

Every HTTP request — what the client sends — has three parts:

1. A request line
2. Headers
3. (Sometimes) a body

Let’s look at what a real one looks like.

GET /about HTTP/1.1
Host: readunderstory.ink
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
Accept: text/html
Accept-Language: en-US,en;q=0.9
Connection: keep-alive

That’s it. That’s a complete HTTP request. Four headers, one request line, no body. Small enough to fit on a napkin. And this is what your browser is sending to websites millions of times per day.

Let’s break it down.

The request line

HTTP method — A token in the request line of an HTTP request that indicates the desired action to be performed on the target resource. The standard methods are GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, TRACE, and CONNECT.

In plain terms: “The verb. GET /about asks for the About page; DELETE /about would destroy it. Same noun, different intention.”

GET /about HTTP/1.1

Three pieces, in order:

  • GET — the method. It says what kind of action you want to perform. “Get this thing for me.” We’ll do a full day on methods tomorrow.
  • /about — the path. It says which resource you want. Everything on a server has a name, and this is the name you’re asking for.
  • HTTP/1.1 — the protocol version. Says which version of the HTTP rules you’re speaking. (We’re now on HTTP/2 and HTTP/3 in modern browsers — but HTTP/1.1 is still the clearest to read and learn from.)

The headers

Host: readunderstory.ink
User-Agent: Mozilla/5.0...
Accept: text/html
Accept-Language: en-US,en;q=0.9
Connection: keep-alive

Headers are little key: value pairs that give extra context about the request.

Header — A key: value line in an HTTP message carrying metadata about the message or the entity it describes — who is asking, what formats are acceptable, how the body is encoded, or how long the response may be cached.

In plain terms: “The labels on the envelope. Never the letter itself.”

  • Host — which website you’re asking about. Yes, this seems obvious, but one server can host many websites. This tells it which one you want.
  • User-Agent — what client is making the request. “Hi, I’m Chrome on a Mac.” Servers use this to serve different content to different browsers or devices.
  • Accept — what format the client can handle. “I can take HTML.” This is the client being polite about its preferences.
  • Accept-Language — what language the client prefers. “I speak English, but French would be OK too.” This is how websites know to show you English.
  • Connection — should the connection stay open after this request? keep-alive means “yes, I’ll probably make more requests, don’t hang up.”

Analogy: If the request line is the question (“Can I see the About page?”), headers are the context around it: who’s asking, what language they speak, what format they want the answer in, and whether they’re planning to ask more questions.

The body (optional)

Body — The payload of an HTTP message: the bytes actually being transferred, whose type and size are declared by the Content-Type and Content-Length headers. Optional in a request, usual in a response.

In plain terms: “The contents of the envelope.”

Most GET requests don’t have a body. But when a client is sending data — like a login form, a post submission, a file upload — the body carries that data.

POST /login HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 47

{"username": "ada", "password": "secret123"}

See the JSON at the bottom? That’s the body. It’s the payload — the actual thing being sent.

The headers are still the context, but now they include Content-Type and Content-Length, telling the server what kind of data is coming and how big it is.

The anatomy of a response

Response — A message sent by a server in reply to a request, containing a status code, headers, and usually a body.

In plain terms: “The answer.”

Now the server replies. Every HTTP response also has three parts:

1. A status line
2. Headers
3. (Usually) a body

Here’s what a response looks like:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1284
Cache-Control: max-age=3600
Set-Cookie: session=abc123; Path=/; HttpOnly

<!DOCTYPE html>
<html>
  <head><title>About</title></head>
  ...
</html>

The status line

HTTP status code — A three-digit integer in the status line of an HTTP response that indicates the outcome of the request. Defined by the HTTP specification and maintained in a public registry by IANA.

In plain terms: “The one-word verdict on the whole request. Programs read the number; the words after it are for humans.”

HTTP/1.1 200 OK

Three pieces:

  • HTTP/1.1 — protocol version.
  • 200 — the status code. Three digits. Tells you how the request went. We’ll do a full day on these soon.
  • OK — the reason phrase. Human-readable label for the code. Purely descriptive — programs care about the number, not the words.

The headers (again)

Content-Type: text/html; charset=utf-8
Content-Length: 1284
Cache-Control: max-age=3600
Set-Cookie: session=abc123; Path=/; HttpOnly

Server headers do the same job client headers do — provide context. Some important ones:

  • Content-Type — what kind of content is in the body. “This is HTML.” Or “This is JSON.” Or “This is a JPEG.”
  • Content-Length — how big the body is, in bytes.
  • Cache-Control — how long the client should cache this. “You can keep this for an hour before asking again.”
  • Set-Cookie — tells the client to store a cookie. We’ll do a day on this too.

The body

The body is the actual content — the HTML of the page, the JSON of an API response, the bytes of an image.

For the About page we requested, the body is the HTML that renders the page. Simple.

The devil in the details: character encoding and mojibake

Let’s pause here, because this is where a lot of real-world bugs live — and where a word you asked about finally makes sense.

Look at this header again:

Content-Type: text/html; charset=utf-8

Charset — The declared character encoding of a document’s bytes, named in the charset parameter of a Content-Type header. It tells the client which mapping to use when turning bytes back into characters.

In plain terms: “The label that says which key to read this file with.”

That charset=utf-8 is doing more than it looks like. It’s telling the client which character encoding to use to read the bytes of the body.

Character encoding — A defined mapping between numbers and characters, specifying which byte sequence represents which character in a text.

In plain terms: “A codebook: this number means this letter.”

A character encoding is a system for mapping numbers to characters. Computers only understand bytes — numbers from 0 to 255. To store text, you need a convention: “this number means this letter.”

  • ASCII — the oldest. Only 128 characters. English letters, digits, punctuation. Cannot represent é, ñ, ọ, Chinese, Arabic, emoji, or anything non-English. This is why the early internet was English-centric.
  • Latin-1 (ISO-8859-1) — extended ASCII to 256 characters. Added Western European accented letters. Still can’t handle most languages.
  • UTF-8 — the modern standard. Can represent every character in every human language, plus emoji. It’s a variable-length encoding: common English letters take 1 byte, others take 2–4. This is what the web uses now, almost universally.

UTF-8 — A variable-length character encoding that can represent every character in Unicode. Each character occupies one to four bytes: ASCII characters take one byte, most other scripts take two or three, and emoji take four.

In plain terms: “One codebook for every language, sized to fit — cheap for English, roomy for everything else.”

Here’s where it goes wrong: if the server says “this content is UTF-8” but the client reads it as Latin-1 (or vice versa), the bytes get misinterpreted and you get garbage on screen.

That garbage has a name. That name is mojibake.

Mojibake — Text corruption caused by decoding a byte sequence with the wrong character encoding, so each byte is mapped to a character other than the one intended.

In plain terms: “Not corruption. The wrong key in the lock.”

You’ve seen it. Maybe you’ve seen it without knowing what it’s called:

  • é when it should be é
  • ’ when it should be '
  • ñ when it should be ñ
  • أهلاً when it should be أهلاً

The word comes from Japanese: 文字化け — moji (character) + bake (transform, change). Literally “character transformation.” Japanese developers named the phenomenon in the 1980s when it plagued their systems, and the word stuck in English because there was no better one.

Analogy: Imagine you hand someone a letter written in Russian Cyrillic, and they try to read it using the English alphabet’s rules. Every letter becomes nonsense. They’re reading real symbols — they’re just using the wrong key. Mojibake is exactly that, but for bytes.

Why you should care: if you ever build an API, serve a file, or render user-submitted text, and you forget to declare (or correctly handle) encoding — you’ll see mojibake. And so will your users. The fix is almost always: declare charset=utf-8 in your Content-Type header, and make sure your text actually is UTF-8.

That’s why the header matters. It’s a tiny string that decides whether a page reads beautifully or looks like a broken password.

HTTP is stateless — and that’s a bigger deal than it sounds

One concept before we get to HTTPS. It’s short but essential.

HTTP is stateless. Every request is independent. The server doesn’t remember your last request. It doesn’t remember your name. It doesn’t remember you logged in two seconds ago.

Analogy: Imagine going to a market where the trader has amnesia. Every time you walk up to her stall, she has no idea who you are or what you bought five minutes ago. You’d have to reintroduce yourself and re-explain your situation every single time.

That’s HTTP. Every request is a stranger. Every response is a fresh start.

So how do websites know you’re logged in? How does Twitter remember your feed? How does Gmail know your emails are yours?

The answer is a mechanism called cookies — a way of storing a small piece of data on the client, which it sends back with every request, so the server can recognise you. Cookies are how stateless HTTP pretends to have a memory.

We’ll do a full day on cookies and sessions soon. For now, just sit with this: HTTP remembers nothing. Everything that feels like memory is a clever trick built on top.

HTTPS — the same language, but encrypted

HTTPS — HTTP transmitted over a TLS-encrypted connection. The message format is unchanged; the entire conversation is confidential and tamper-resistant.

In plain terms: “The same letters, in a sealed envelope only the recipient can open.”

Now we get to HTTPS. And the good news is: HTTPS is just HTTP with encryption.

That’s genuinely it. Same request format. Same headers. Same status codes. Same body structure. Same everything. The only difference is that the whole conversation is wrapped in a cryptographic layer that makes it unreadable to anyone listening in the middle.

HTTP = plain text. Anyone can read it. HTTPS = encrypted. Only the client and server can read it.

The “S” stands for Secure. And that secure layer is called TLS — Transport Layer Security.

TLS — Transport Layer Security: the cryptographic protocol that provides confidentiality, integrity, and server authentication for a connection. The successor to SSL, standardised in 1999 as TLS 1.0, now at TLS 1.3.

In plain terms: “The locked tunnel the conversation travels through.”

A brief note on SSL vs TLS

SSL — Secure Sockets Layer: the encryption protocol Netscape developed in the 1990s and the direct ancestor of TLS. Deprecated because of vulnerabilities, but its name survives in everyday speech.

In plain terms: “The old name for the lock. The lock was replaced; the name stuck.”

You’ll hear “SSL” everywhere. It’s technically wrong. Here’s the story:

  • SSL (Secure Sockets Layer) was the original encryption protocol, invented by Netscape in the mid-1990s.
  • SSL 1.0 was never released. SSL 2.0 came out in 1995. SSL 3.0 in 1996.
  • SSL 3.0 had serious flaws. So in 1999, a new protocol was created called TLS 1.0 — basically SSL 3.0 with the vulnerabilities fixed.
  • TLS 1.1, 1.2, and 1.3 followed. We’re on TLS 1.3 now.
  • But the world got used to saying “SSL.” So even though the actual protocol is TLS, everyone — including most developers — still says “SSL.”

Rule of thumb: say TLS when you want to sound precise. Say SSL when you want to sound normal. Either way, you’re referring to the same layer.

How the padlock works

Certificate — A digitally signed document, issued by a certificate authority, that binds a public key to a domain name. A client validates it during the TLS handshake to confirm it is talking to the server it intended to reach.

In plain terms: “A passport the server shows before you hand over anything.”

When you see the padlock in your browser’s address bar, here’s what’s actually happening under the hood — in three steps:

  1. The handshake. When your browser connects to an HTTPS server, they do a cryptographic dance called a TLS handshake. Your browser says “hello.” The server sends back its certificate — a digital document that proves its identity. The browser checks the certificate against a list of trusted authorities. If it checks out, they agree on an encryption key.
  2. The tunnel. Once the handshake is done, both sides share a secret key. Everything from here on out — every request, every response — is encrypted with that key before it goes over the wire.
  3. The verification. If the certificate doesn’t check out, or if it’s expired, or if it belongs to a different domain, your browser shows a big scary warning. That’s the padlock breaking.

Analogy: Imagine you’re sending a letter to a bank. You want to be sure the letter reaches the real bank and not a criminal impersonating one. HTTPS is a system where the bank publishes a public stamp that only the real bank can make, and your browser checks that stamp before trusting anything.

What HTTPS actually protects against

Three main things:

  • Eavesdropping — someone on the same WiFi can’t read your messages. In an open café WiFi, without HTTPS, anyone nearby could read your passwords. With HTTPS, they just see garbled bytes.
  • Tampering — a middle-man can’t modify your data in transit. Your bank statement can’t secretly be changed to say you have ₦50 instead of ₦50,000.
  • Impersonation — a fake server can’t pretend to be your bank. The certificate proves identity.

This is why browsers now actively shame HTTP sites. Chrome and Firefox flag plain HTTP as “Not Secure” in the address bar. It’s not a suggestion anymore — HTTPS is the default.

A bit of history

The story of how HTTPS went from rare to universal is worth knowing — because it shows how the web evolves.

1994 — Netscape invents SSL for its browser. HTTPS is born, but only used for login forms and payment pages. Everything else is plain HTTP.

2000s — HTTPS is still a niche tool. Only banks and e-commerce sites use it. Regular websites are still HTTP. Passwords get sniffed on public WiFi. It’s the wild west.

2010 — Google starts using HTTPS as a ranking signal. Sites with HTTPS rank slightly higher in search. This nudges companies to adopt it.

2014 — Heartbleed — a catastrophic bug in the OpenSSL library — exposes how fragile the trust model is. Also in 2014, Google proposes “HTTPS everywhere” and starts making HTTPS a requirement for many features.

2015–2018 — The Let’s Encrypt project launches, offering free HTTPS certificates. Before this, a certificate cost $50–$100 and required paperwork. Now anyone can get one in seconds. The barrier to HTTPS collapses.

2018–now — Browsers mark all HTTP pages as “Not Secure.” HTTPS becomes the default. Over 95% of web traffic is now encrypted. The web is basically HTTPS-only.

The takeaway: the web isn’t static. Things that seem permanent — like “most sites are HTTP” — can shift in under a decade. Technologies you learn today may be industry standard tomorrow.

What you’d say in the room

If an interviewer asks “What’s the difference between HTTP and HTTPS?” — here’s the answer:

“HTTPS is HTTP wrapped in TLS encryption. The HTTP request-response format is identical — same methods, headers, status codes, body. The difference is that with HTTPS, the entire conversation is encrypted. When a client first connects to an HTTPS server, they do a TLS handshake where the server proves its identity with a certificate, and both sides agree on an encryption key. Everything after that is encrypted. HTTPS protects against eavesdropping, tampering, and impersonation. Modern browsers flag HTTP sites as ‘Not Secure,’ and today over 95% of web traffic is HTTPS.”

That’s a whole answer. Learn it.

Say it like a professional

The definitions from today, in one reviewable block. Say each one out loud. If you stumble, go back to that section.

  • HTTP — HyperText Transfer Protocol: the application-layer protocol that defines how clients and servers exchange messages on the web, including the shape of a request, the shape of a response, and the meaning of the methods and status codes inside them.
  • HTTPS — HTTP transmitted over a TLS-encrypted connection. The message format is unchanged; the entire conversation is confidential and tamper-resistant.
  • Request — A message sent by a client asking a server to perform an action or return a resource, containing a method, a target, headers, and optionally a body.
  • Response — A message sent by a server in reply to a request, containing a status code, headers, and usually a body.
  • HTTP method — A token in the request line of an HTTP request that indicates the desired action to be performed on the target resource. The standard methods are GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, TRACE, and CONNECT.
  • HTTP status code — A three-digit integer in the status line of an HTTP response that indicates the outcome of the request. Defined by the HTTP specification and maintained in a public registry by IANA.
  • Header — A key: value line in an HTTP message carrying metadata about the message or the entity it describes — who is asking, what formats are acceptable, how the body is encoded, or how long the response may be cached.
  • Body — The payload of an HTTP message: the bytes actually being transferred, whose type and size are declared by the Content-Type and Content-Length headers. Optional in a request, usual in a response.
  • URL — Uniform Resource Locator: a string that identifies a resource on the web and names the scheme by which to retrieve it, composed of a protocol, a domain, a path, an optional query string, and an optional fragment.
  • TLS — Transport Layer Security: the cryptographic protocol that provides confidentiality, integrity, and server authentication for a connection. The successor to SSL, standardised in 1999 as TLS 1.0, now at TLS 1.3.
  • SSL — Secure Sockets Layer: the encryption protocol Netscape developed in the 1990s and the direct ancestor of TLS. Deprecated because of vulnerabilities, but its name survives in everyday speech.
  • Certificate — A digitally signed document, issued by a certificate authority, that binds a public key to a domain name. A client validates it during the TLS handshake to confirm it is talking to the server it intended to reach.
  • Character encoding — A defined mapping between numbers and characters, specifying which byte sequence represents which character in a text.
  • UTF-8 — A variable-length character encoding that can represent every character in Unicode. Each character occupies one to four bytes: ASCII characters take one byte, most other scripts take two or three, and emoji take four.
  • Charset — The declared character encoding of a document’s bytes, named in the charset parameter of a Content-Type header.
  • Mojibake — Text corruption caused by decoding a byte sequence with the wrong character encoding, so each byte is mapped to a character other than the one intended.

Before you close this tab

Say these answers out loud, in your own words, without looking:

  1. What does HTTP stand for? What does the “hypertext” part mean?
  2. What are the three parts of an HTTP request?
  3. What are the three parts of an HTTP response?
  4. What’s the difference between the request line and the headers?
  5. What is a character encoding? What’s the difference between ASCII, Latin-1, and UTF-8?
  6. What is mojibake, and what causes it?
  7. What does the charset=utf-8 in a Content-Type header actually do?
  8. What does “HTTP is stateless” mean?
  9. What does the “S” in HTTPS stand for? What’s the protocol that provides it?
  10. Why do we say “SSL” when we mean “TLS”?
  11. What are the three things HTTPS protects against?

If you can answer all eleven without peeking — you’ve done Day 3.

If some are fuzzy, read those sections again. Especially #6 and #7 — mojibake is one of those things that feels obscure until you see it, and then you see it everywhere.

Tomorrow, we put the whole machine together: the full journey of a page load. From your tap to rendered pixels — URL parsing, DNS, the TCP and TLS handshakes, the request, the response, and rendering, in order. When something breaks, you’ll know exactly which step to blame.

Close the loop

0/3 sentences

---