HTTP: Ask and Receive

Tessa's next question to Milo is the practical one. That block of text on his screen — how does it get from his laptop to the provider and back? What carries it?

The answer is a set of rules called HTTP, and she has been using it every day for twenty years without ever being told its name. HTTP is the ask-and-receive agreement that the whole web runs on: how one machine phrases a request, how the other machine phrases its answer. Every page she has ever loaded, every photo, every form she has submitted, arrived this way. The request Milo showed her is one more instance of the most ordinary thing on the internet.

She needs it only as a working idea — something goes out, something comes back, and a three-digit number says how it went. That is genuinely all this book requires, and it is deliberately less than a networking course would teach. But the working idea is about to explain every error message she has ever shrugged at.

The request goes outaddress · verb · body

→

The server takes itor declines before any work starts

→

A response comes backthree-digit code · body

→

Or nothing comes backa timeout · an open question

Request and Response

An exchange has exactly two halves, and each half has a fixed shape.

The first half is the request, and it carries three things. An address, saying which machine and which service is being asked. A verb, saying what kind of asking this is: GET means "send me this", POST means "here is some material, do something with it". And often a body — the material itself, when there is any. Loading a web page is a GET with no body. Submitting a form is a POST whose body is what you typed.

The second half is the response, and it carries two things. A status code, three digits saying how the request went. And a body, the actual content: the page, the picture, the answer.

That is the entire loop, repeated some unfathomable number of times per second across the world, and the model call is one more member of the family. Tessa's message is a POST — she is handing over material and asking for something to be done with it. The body of her request is the conversation. The body of the response is the reply. Nothing about it is exotic; it is the same machinery as clicking a link, carrying different cargo.

Status Codes: the Three-Digit Verdict

The status code is the most useful thing in this chapter per second of study, because you do not have to memorize codes to read them. You have to memorize one rule: the first digit tells you whose problem it is.

A code starting with 2 means it worked. In practice this is 200, and 200 is the only cheerful number in the chapter.

A code starting with 4 means the problem is on the asking side. Something about the request was wrong, and the server is telling you so rather than failing. Three of these matter here. 400 means the request itself was malformed — a missing label, a stray comma, something the server could not make sense of. 401 means the credentials were missing or wrong: the server does not accept that you are who you say you are. 429 means you are asking too often and are over the allowed rate.

A code starting with 5 means the problem is on the answering side. 500 is the general one: the server tried, something failed inside it, and this has nothing to do with what you sent. You could send the identical request a minute later and get a perfectly good answer.

There are other families of codes — one for "it moved, look over there", for instance — and a working professional meets them eventually. For everything in this book, 2 means yes, 4 means look at your request, 5 means look at their servers. That one sentence turns a wall of numbers into a diagnosis.

Think of the deli counter at lunchtime. You ask for a sandwich and you get a sandwich: 200. You hand over a scribbled order slip nobody can read: 400. Your name is not on the account list and they will not put it on the tab: 401. You have ordered four times in two minutes and are asked to wait your turn: 429. And once in a great while something goes badly wrong in the kitchen, through no fault of yours at all: 500. Four of those five are about the ordering, not the food — which is exactly the proportion in real life, and exactly why "the AI is broken" is almost always the wrong first sentence.

Timeouts: When No Answer Comes

There is a fifth ending, and it is the strange one. Sometimes no response arrives at all.

The asking machine does not wait forever. It sets itself a limit — a few seconds, a minute, whatever the program's author chose — and if nothing has come back by then it gives up and reports a timeout. A timeout is not a status code. It is the absence of one, which is a different kind of thing entirely.

Here is the part worth sitting with, because it is the honest heart of this chapter. A timeout tells you nothing about whether the work happened. Perhaps the request never reached the server, and nothing was done. Perhaps it arrived, the model produced an entire answer, and the response was lost on its way home. Perhaps it is still being worked on right now and will finish thirty seconds after you gave up listening. From where you stand, those look identical.

Every other ending gives you a fact. The timeout gives you an open question, and there is no way to close it from your side. That is not a flaw in the design; it is what happens when two machines that cannot see each other are separated by a network. The consequences are large enough to need their own page, and they get one two pages from here.

Told as One Story

Tessa sends her message. There are five ways this afternoon can go.

It works: 200, the reply arrives, and she gets on with her day. This is the overwhelming majority of the time, and it is worth saying so before the failure cases make the picture look grim.

The account string in her request is wrong or expired: 401. Nothing is broken and nothing will improve on its own. Fix the credential, send again, done — and the page after next is about that credential.

She is running her review script and it fires off requests as fast as it can: 429. The provider is not refusing her, it is pacing her. The fix is to slow down, which is a stranger instruction than it sounds and gets its own page.

Something fails inside the provider's systems: 500. Not her fault, not her fix, and waiting a little is usually the whole remedy. If it lasts, the provider's status page is where she looks, not her own settings.

Or nothing comes back at all: a timeout, and an open question about whether the work happened. She will meet all five endings, and so will every product Waymark ever plugs into. Knowing which is which is the difference between an afternoon of confusion and a sentence like "we are being rate-limited, give it a minute".