Foundations — HTTP - 1.1 — methods, status codes, headers, persistent connections

This page assumes you know nothing. Before you can read the parent topic, you need a handful of ideas locked in. We build each one from a picture, say why the topic needs it, and only then use its notation.

0. What even is a "protocol"?

Picture: two people on a phone who agreed in advance "I say hello, then you say hello, then I ask my question." Neither talks over the other; both know when the other is done.

Why the topic needs it: HTTP is a protocol. Every rule in the parent note ("start line first", "blank line ends the headers") is just one clause of that agreement.

1. Client and Server — the two roles

Figure 1 walkthrough: the cyan box on the left is the client; the amber box on the right is the server. The top white arrow (client → server) is the request; the bottom white arrow (server → client) is the response. Reading direction never flips: in HTTP/1.1 the client always speaks first.

Why the topic needs it: Every HTTP message is either a request (client → server) or a response (server → client). The whole "request–response" phrase in the parent note is built on these two roles.

2. TCP — the reliable pipe HTTP rides on

Here is the single most important background fact: HTTP does not move bytes across the internet itself. It hands its text to a lower layer called TCP.

Picture: a garden hose connecting client and server. HTTP text is the water. TCP guarantees the water arrives in order.

2a. The 3-way handshake — why opening a pipe costs time

Before any HTTP text can flow, TCP must open the pipe. It does this with three small messages back and forth.

Figure 2 walkthrough: the cyan vertical line is the client's timeline, the amber line is the server's; time runs downward. The three white arrows are the handshake messages (SYN, then SYN-ACK, then ACK). The amber double-headed arrow on the left marks that a full 1 RTT has been burned before the cyan note "only NOW can HTTP text flow" — no web data moves until the pipe is open.

The handshake spends 1 RTT before you can send even a single byte of HTTP. That one fact is the entire reason persistent connections exist: opening a fresh pipe for every image wastes one RTT each time. See TCP three-way handshake for the full mechanics.

3. Bytes, characters, and CRLF — the fabric of the message

HTTP is a text protocol. To read the parent note you must be comfortable with three tiny ideas.

Picture: an old typewriter. CR = slide the carriage back to the left margin; LF = roll the paper up one line. Two mechanical actions = one new line. HTTP inherited that pairing.

4. URL and path — what you're asking for

Picture: an address on an envelope. The domain is the building; the path is the room number inside it.

Why the topic needs it: the request start line is METHOD /path HTTP/1.1. And because the domain is split off into Host:, one building (one server IP) can hold many companies — that is Virtual hosting, and it's why Host: became mandatory in 1.1.

5. Header — a labelled fact, Name: Value

Picture: the fields on a shipping form — "Weight: 2kg", "Contents: books". Each is a name colon a value; the parser reads them one line at a time until the blank line.

Why the topic needs it: every capability in the parent note (caching via ETag, sessions via Cookie, framing via Content-Length) is just a header. Master the Name: Value shape and the header list stops being scary.

6. Method — the action verb of a request

Picture: a form at a counter with a checkbox — READ / ADD / REPLACE / REMOVE. The method is which box you tick; the URL is which record you tick it for.

Why the topic needs it: the request start line is literally METHOD /path HTTP/1.1. The parent note's entire "methods" table is just this verb, and the next section (safe/idempotent) describes properties these verbs have.

7. Idempotent and Safe — properties of a method

These two adjectives describe methods (GET, POST…). They confuse people because they sound similar.

Picture:

• Safe = reading a book from a shelf. Read it 100 times; the shelf is unchanged. (GET.)
• Idempotent = a light switch set to OFF. Flip-to-OFF once or ten times → still OFF. (PUT, DELETE.)
• Neither = adding a coin to a jar. Each repeat adds another coin — state keeps changing. (POST.)

8. Status code — a 3-digit verdict

Picture: a traffic-light system with five colours — you glance at the first digit and instantly know the mood before reading details.

Why the topic needs it: it's half of the response. Knowing "4 = client, 5 = server" lets you debug most HTTP problems from the code alone.

9. Putting it together — a full HTTP message

Now every ingredient (method, path, version, headers, blank line, body, status code) has a meaning. Here is one complete request and one complete response, drawn line by line.

Figure 3 walkthrough: read top to bottom.

• The cyan first line is the start line: on the request it's GET /index.html HTTP/1.1 (method, path, version); on the response it's HTTP/1.1 200 OK (version, status code, reason phrase).
• The white boxes are headers, each in Name: Value shape.
• The amber box is the blank line \r\n\r\n — the hard boundary that says "headers finished".
• The cyan bottom box is the body (here Hello, world!, 13 bytes — matching the response's Content-Length: 13).

This is the exact skeleton the parent note assumes. You no longer need it to see the shape — it's above, fully labelled.

Prerequisite map

The picture below shows how each foundation feeds into the next, ending at the HTTP/1.1 topic. Read an arrow "A → B" as "you need A before B makes sense."

If any box is fuzzy, the parent note will feel like memorization instead of understanding.

Equipment checklist

Cover the right side and test yourself — you should answer each in one breath.