Introduction — Reading the HTTP conversation between browser and server
Locate HTTP within what happens after typing a URL (DNS → TCP → TLS → HTTP), and grasp the skeleton of raw request and response text along with the meaning of stateless.
You opened the Network tab, but where do you even look?
A page will not render, an API does not behave as expected — you ask a senior colleague and hear "look at the Network tab in DevTools". You open it, and rows of entries and numbers stretch out with no obvious place to start reading. Everyone who has just started building for the Web has been in this scene.
In truth, what that screen shows is something very plain. Browser and server are simply exchanging letters written in text, one round trip at a time. The browser sends a letter saying "please give me this" (the request), and the server returns a letter saying "here you are, and this is how it went" (the response). Once you know the format of this correspondence, the Network tab and curl output can both be read with the same skeleton.
Throughout this course, whatever output you are looking at, you check the same three things.
Before HTTP begins — what happens after you type a URL
When you type https://example.com/ into the browser and press Enter, several preparations stack up before the HTTP letter is sent.
example.com, the server's IP address is looked up. Without the recipient's address, no letter can be senthttp:// this step is skipped and the letters travel in plaintextWhat matters is the division of labor between layers. DNS handles addresses, TCP handles transport, TLS handles the envelope — and HTTP is the letter's text itself. Even with HTTPS, the letter's format (everything this course teaches) does not change; the only difference is whether it goes into an envelope.
Request and response only differ in direction; the skeleton is the same "first line + headers + blank line + body". Only the first line changes shape with its role — the asking side has a request line, the answering side a status line.
Reading the raw text
Let us look at a real round trip, completely unprocessed. First, the request the browser sends.
GET /docs/index.html HTTP/1.1
Host: example.com
Accept: text/html
The first line is the request line. It lists three items separated by spaces: GET (what you want to do = method), /docs/index.html (what you want it done to = path), and HTTP/1.1 (which version you are speaking = version). From the second line on come the headers in Name: value form, and a blank line signals "the heading ends here". A GET request is only a favor asked, so the body after the blank line is empty.
The server's response comes back with the same skeleton.
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256
<!DOCTYPE html>
<html>...
The first line is the status line. 200 is the 3-digit result code for machines, OK the supplementary phrase for humans. The headers that follow add notes like "this is HTML, 1256 bytes", and after the blank line the requested thing (the HTML text) arrives as the body.
This is the foundation of the whole course: both request and response are "first line + headers + blank line + body". Read the first line and you know "what was asked" and "how it went"; read the headers and you know "the conditions and notes".
Practice 1-1 — The road from typing a URL to HTTP
Check what happens before HTTP begins, and how to read the first line of a request.
Q1. After typing https://example.com/ into the browser, which is the correct order of what happens before the HTTP request is sent?
To send a letter you first need the address (looking up the IP address via DNS), then the road (a TCP connection), and for HTTPS the sealed envelope (TLS) — the HTTP conversation begins on top of all that. You cannot send the HTTP request first (you do not yet know where to send it), and TLS is built on top of TCP so it cannot come before it. What this course reads is the topmost layer of this stack.
Q2. Which is the correct reading of the first line of a request, GET /docs/index.html HTTP/1.1?
The request line is 'verb + object + which edition of the language'. GET is what you want to do (retrieve), /docs/index.html is what you want it done to, and HTTP/1.1 is which version of HTTP you are speaking. A status code appears in the first line on the response side, never in the request line. If you can read this triple, you can always answer 'what was asked'.
Q3. In an HTTP request or response, what separates the end of the headers from the start of the body?
After listing the headers line by line, one blank line signals 'the body starts here'. In a letter, it plays the same role as the empty line after the heading. There is no END terminator or special binary marker — an HTTP/1.1 message can be read to the end purely by textual conventions.
Stateless — the server does not remember "where we left off"
This correspondence has a property that surprises every beginner at first. As a rule, the server does not remember previous requests. Even if you viewed a product page in letter one and added it to the cart in letter two, to the server the second letter is "a new letter from a stranger". This is called being stateless.
It looks inconvenient, but it is a deliberate design choice. Because each request is self-contained, the server can process letters independently, one at a time, and share the work across any number of machines. Planet-scale services are possible thanks to exactly this trade-off.
Then how is a "serial story" like a login session achieved? The answer is to attach a name tag to every letter — a marker issued by the server (a Cookie) that the browser writes onto every subsequent request. The mechanism is read in Chapter 4; for now, just keep the picture that "state is built on top of a stateless correspondence, using margin notes".
Practice 1-2 — Reading the response, and stateless
Check the first line on the answering side, and HTTP's important property of being stateless.
Q4. Which correctly describes the 200 and OK in the response's first line, HTTP/1.1 200 OK?
The status line is 'version + 3-digit status code + human-oriented phrase'. What programs use for decisions is the number 200; OK is merely a note for the human reader. Results are judged by these three digits — this is how you read the second item of the three-part set, 'how did it go', which Chapter 3 explores digit by digit.
Q5. HTTP is said to be 'stateless'. Which explanation is correct?
Stateless means 'holding no state' — each request is self-contained, and the server does not automatically remember 'the continuation of what came before'. That is exactly why every request must carry all the information it needs, and why a 'serial story' like a login session is built with the margin-note mechanism called Cookies, covered in Chapter 4. It is not about encryption or the number of simultaneous connections.
What to take from this chapter
- HTTP is a textual correspondence exchanged on top of the preparations DNS → TCP → TLS
- Request and response share the same skeleton: "first line + headers + blank line + body". The first line is either a request line (method, path, version) or a status line (version, 3-digit code, phrase)
- HTTP is stateless — each request is an independent letter. "Serial stories" are built with margin notes such as Cookies
- The reading is always the three-part set — what was asked, how it went, and what conditions and notes are attached
The next chapter digs into the first of the three, "what was asked". How do GET and POST differ, and which favors are safe to send twice — we read the promises of the methods.