HTTP, HTTPS & TLS Basics

Once a client knows the server's address (DNS gave it that), the two need a shared language for the conversation itself: how to ask for something, and how to say it worked or why it did not. For almost everything on the web, that language is HTTP, the HyperText Transfer Protocol. You have already seen a request and a response. This chapter explains the rules behind them, the one design choice that shapes a whole course (statelessness), and what the S in HTTPS adds.

Picture a busy fast-food counter where every cashier has total amnesia. You ask for a burger and get it. You walk away, come back a minute later, and the cashier has no idea who you are or that you were just here. This is how HTTP behaves: each request stands alone, and the server does not automatically remember anything about the previous one.

That sounds like a flaw, and it is a deliberate choice, because it has a huge benefit. If no cashier remembers anything, you can go to any cashier. Replace one, or open ten more counters, and nothing breaks. Swap cashier for server and you have the reason a system can add more servers freely. Statelessness is what makes horizontal scaling (adding more machines) possible, which is the subject of the next module.

But real apps do need memory: you stay logged in, and your basket remembers what is in it. The trick is to move the memory out of the cashier and into something you carry. When you log in, the server hands your browser a small piece of data called a cookie, such as session=abc123. From then on your browser attaches that cookie to every request, like showing your loyalty card at every counter. Any server can read the card and look up who you are in a shared store that all of them can reach, so no single server has to be the one that remembers you.

POST means here is some data. The path names what you want done, the headers give context, and the body carries the data itself. In the response, the status code on the first line says how it went, and the Set-Cookie header is the server handing your browser its card. On the next request, your browser will send Cookie: session=abc123 without being asked.

• -GET reads something and changes nothing.
• -POST sends data to create something or trigger an action.
• -PUT and PATCH change something that already exists (PUT replaces it, PATCH edits part of it).
• -DELETE removes something.

The first line of every response carries a three-digit status code, and the first digit tells you the family. A handy way to remember them is to ask who has to do something next.

• -2xx, it worked: 200 OK, 201 Created.
• -3xx, look elsewhere: what you want has moved or has not changed. 301 Moved Permanently, 304 Not Modified.
• -4xx, your fault: the client sent something wrong. 400 Bad Request, 401 Unauthorized (who are you?), 403 Forbidden (I know who you are, and the answer is no), 404 Not Found, 429 Too Many Requests (slow down).
• -5xx, our fault: the server failed to do something reasonable. 500 Internal Server Error, 503 Service Unavailable (down or overloaded).

This matters for design because the families are handled differently. A client can fix a 4xx by changing its request, but only the owner of the server can fix a 5xx, and a retry only makes sense for some of them.

Plain HTTP is a postcard. Everyone who handles it on the way (the cafe Wi-Fi, the internet provider, a router in between) can read it, and could even change it. TLS, Transport Layer Security, turns the postcard into a sealed, signed envelope. HTTP carried inside a TLS connection is what we call HTTPS. TLS gives you three separate guarantees:

• -Encryption (sealed): nobody along the way can read the contents.
• -Integrity (tamper-evident): nobody can change the contents without the receiver noticing.
• -Authentication (signed by someone you can check): you can verify that you really are talking to the website you meant, not an impostor. The server proves it with a certificate, like an ID card issued by a trusted authority, and your browser ships with a list of authorities it trusts.

Before any HTTP is sent, the two sides do a short handshake: the browser says which encryption it supports, the server shows its certificate, and they use some clever mathematics to agree on a secret key that only the two of them know. From then on every message is encrypted with that key. Modern TLS (version 1.3) needs just one round trip before the real request can go. That small cost is why HTTPS everywhere is the default for every production system in this course.

HTTP itself has also been sped up over the years. The block below is a quick map of the versions you will hear about.