New: Try Voli The Bear, Fast package manager (and not only) for Windows
The Missing Manual
/
← Back to guide / Phase 3
Updated Jul 10, 2026 Edit on GitHub

Headers, Cookies & the S in HTTPS

You've got the core conversation down: request out, response back, verb on one side, status on the other. But we kept waving at some "extra notes" on each message. This phase opens them up.

Those notes are headers, and they carry everything that isn't the main content - what format the body is in, who you are, whether the site is allowed to remember you. Out of headers come cookies (how a site knows it's still you on the next click) and a lot of what makes HTTPS trustworthy.

Headers - the notes on every message

A header is a single Name: Value line attached to a request or response, carrying information about the message rather than the message itself. You saw a few in Phase 1: Host, Content-Type, Content-Length. There can be many, and both sides use them.

Think of mailing a package: the body is what's inside the box, headers are everything written on it - who it's for, what's in it, whether it's fragile. The server reads the labels before it opens the package.

📝 Terminology. Header = one Name: Value line of metadata on an HTTP message. Body = the actual content (the HTML, the JSON, the image). Headers describe; the body delivers.

A handful you'll genuinely run into:

  • Content-Type - what kind of thing the body is: text/html for a page, application/json for data, image/png for an image. This is how your browser knows whether to draw the body or download it.
  • Authorization - proof of who you are, when a request needs it. The proper place for a secret token or credentials - a header, not stapled into the visible URL (remember the query-string warning from Phase 1).
  • User-Agent - a description of the client itself (which browser, which version) - how a server tells a phone from a desktop.
  • Cache-Control - instructions about reuse: "keep a copy for an hour" versus "always ask me fresh."

Here's a request and the start of its response, headers and all:

GET /account HTTP/1.1
Host: example.com
Authorization: Bearer a1b2c3d4e5
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: no-store

<!DOCTYPE html> ...

What just happened: the client proved who it was with an Authorization header (the Bearer ... token is its ID badge) and asked for HTML back. The server approved, labelled its answer Content-Type: text/html so the browser knows to render it, and added Cache-Control: no-store - "don't keep a copy of this account page lying around." Neither side put any of that in the URL or the body; the headers carried it.

Half the puzzling moments in web work are a header doing its job quietly - a file downloading instead of displaying (wrong Content-Type), a request rejected as unauthorized (missing Authorization), a page stubbornly showing old content (Cache-Control). Once you know headers exist, those stop being mysteries and become a place to look.

Cookies - how a site remembers you

HTTP has a problem by nature: each request stands completely alone. The server answers and then, in effect, forgets you exist - the next request is a stranger all over again. So how does a site keep you logged in across a dozen clicks? With a cookie.

📝 Terminology. A cookie is a small piece of text a server asks your browser to hold onto and hand back on every future request to that site - the site's way of pinning a name tag on you.

The mechanism is two ordinary headers, one on the way down, one on the way back up:

HTTP/1.1 200 OK
Set-Cookie: session=7f3a9b2c; HttpOnly; Secure

What just happened: when you logged in, the server's response included Set-Cookie: "here's a token, session=7f3a9b2c - hold onto this." Your browser quietly saved it. HttpOnly and Secure are guardrails, telling the browser to keep the cookie out of reach of page scripts and to send it only over encrypted connections.

From then on, your browser includes it automatically on every request back to that site:

GET /account HTTP/1.1
Host: example.com
Cookie: session=7f3a9b2c

What just happened: the browser attached the cookie in a Cookie header, without you doing anything. The server reads session=7f3a9b2c, looks it up, recognizes "this is the person who logged in earlier," and shows your account. Set-Cookie down, Cookie back up on every request - that's how a stack of forgetful, independent requests adds up to staying logged in.

That same mechanism is why cookies get talked about for tracking: a cookie that follows you around can recognize you across pages and visits. The technology is neutral - the same name tag whether it's keeping you logged in or watching where you go.

⚠️ Gotcha. A cookie is only as private as the connection it travels on. Over plain http://, anyone sitting between you and the server can read that Cookie: session=... header as it goes by - and a stolen session cookie can let someone impersonate you without ever knowing your password. This is the single biggest reason the next section exists: cookies and HTTPS are a package deal.

The S in HTTPS - encryption, plainly

https:// is the same HTTP you've learned this whole guide - same requests, responses, headers - wrapped in a layer that encrypts the conversation. The "S" stands for "Secure," and it buys you two things:

  • Privacy. Anyone who can see your traffic - café Wi-Fi, your ISP, a machine in the middle - sees only scrambled noise, not the page you're reading or the cookie you're sending.
  • Integrity. Nobody in the middle can quietly alter the page on its way to you - inject an ad, swap a download, change an account number. Tampered bytes are detectable.

(There's a third thing - confidence you're really talking to who you think you are, via certificates - but privacy and integrity are the heart of it.)

A common belief is that HTTPS means "this website is safe / trustworthy." It doesn't. HTTPS protects the conversation, not the intentions of whoever's on the other end - a scam site can have a perfect padlock. The padlock means "no one is eavesdropping on or tampering with what you send" - not "this server is run by good people." Conflating those is how people get caught out.

The encryption HTTPS adds doesn't live inside HTTP - it's a separate layer (called TLS) sitting just beneath it, scrambling bytes before they're sent and unscrambling them on arrival. HTTP doesn't even know it's there. Where that layer sits relative to everything else is the job of The TCP/IP Model.

⚠️ Gotcha - mixed content. A page loaded over https:// is only fully protected if everything on it also came over https. If a secure page pulls in an image, script, or stylesheet over plain http://, that's mixed content - one insecure piece reopening the hole HTTPS was closing, since it can be read or tampered with in transit. Browsers block the insecure parts or strip the padlock and warn you. A "not fully secure" warning on a site that should be secure usually means one stray http:// link on an otherwise https:// page.

Recap

  1. Headers are Name: Value notes carrying metadata about a message - Content-Type (what the body is), Authorization (who you are), Cache-Control (whether to reuse it), and many more.
  2. Cookies solve HTTP's forgetfulness: the server sends one with Set-Cookie, your browser hands it back in a Cookie header on every request, and that's how you "stay logged in."
  3. A cookie is only as safe as its connection - over plain http, it can be read and stolen.
  4. HTTPS is HTTP plus encryption: it gives you privacy (no eavesdropping) and integrity (no tampering) - but not a promise that the site itself is trustworthy.
  5. Mixed content - an http resource on an https page - quietly undoes that protection, which is why browsers warn about it.

That's the whole everyday picture of HTTP: a request and a response (Phase 1), the verbs and replies they use (Phase 2), and the headers, cookies, and encryption that ride along (Phase 3). You can now read a request, read a response, read a status code, and read the address bar - which is most of what the web is doing, all day, under everything you click.

Want to go a layer deeper - how the bytes actually travel, how a name like example.com becomes a machine you can reach, and where encryption sits in the stack? Continue with How the Internet Works, IP, DNS, and Ports, and The TCP/IP Model.

← Phase 2: Methods & Status Codes · Guide overview

Before the quiz: without looking back, say (or jot down) the core idea of this phase in your own words.

Check your understanding 2 questions

1. A cookie solves HTTP's forgetfulness by...

2. What does HTTPS actually guarantee?