After Four Round Trips of Machinery, What Finally Goes Down the Wire Is a Few Lines of Text You Could Have Typed
Last timeDeciding How Fast to Send
A request and a response are plain lines: a first line, a list of headers, a blank line, a body. Each header is a lever, and knowing which lever does what demystifies most of the stack.
The shape of a message
Four round trips of name lookup, connection setup and key agreement have
happened, and the sender ramps cautiously. What it actually sends is this.
GET /article/42 HTTP/1.1
Host: www.rfc-editor.org
Accept: text/html
Accept-Encoding: gzip
If-None-Match: W/v7-2f19c4
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 18422
ETag: W/v7-2f19c4
Cache-Control: max-age=300
18422 bytes of compressed markup followFour parts, in both directions. A first line that differs between a request and
a response. A list of name and value pairs, one per line. A blank line. Then
optionally a body.
That is the whole format. The newer version of the protocol replaces the text
with a compact binary encoding and compresses the header names, but the parts
and their meanings are identical, which is why reading the text version is
still the way to understand it.
What was asked and how it went
The first line of the request names a method and a path. The method is a
promise about effects.
The lesson stops here
3 more paragraphs to go
You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.
The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.
See the planThe contentsThis is the reading half
Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.
The contents