How does HTTP work

May I have this? Here it is.

Earlier we saw how TCP makes data arrive complete and in order. So what do the browser and the server actually say to each other with the data it carries?
The conversation on the web is very simple. The browser asks the server, "May I have this page?" and the server hands it over: "Here it is." The asking is called a request, and the handing over is called a response. HTTP is the agreement that fixes what requests and responses look like.

Tap the browser to send a request to the server. When the server sends back a response, the pair is complete.

One request, one response. The web runs on this simple pairing. The browser always speaks first, and the server only answers the requests it receives. The server never comes calling on its own.
So all a server has to do is take requests from countless browsers and answer them one by one. But not every request says "may I have this." Each request names the action it wants, and that is what we look at next.

The action in a request

Every request carries an action that says what it wants to do. The most common is GET, which means "please give me this" and fetches something back. Each time you open a page, the request your browser sends is a GET.
On the other side is POST, which means "please take this" and sends something to the server, as when you post a comment or send your username and password to log in. Fetching is GET; sending is POST.

Tap an action to pick it. GET fetches and POST sends. An arrow shows which way the data travels for each action.

Knowing just GET and POST explains most of what we do on the web: GET to open a page and read it, POST to write something and send it.
A response carries a short mark too. It is a three-digit number called a status code: 200 if all went well, 404 if there is no such page. One number tells you whether the request succeeded or failed. For now, remembering these two is enough.

Like a first-time guest, every time

HTTP has one odd trait. Once it has handled a request, it completely forgets who just asked for what. Even if the same person comes twice, it treats them like a first-time guest every time.
It has no memory of "weren't you here a moment ago?" Not remembering past requests like this is called having no state, or being stateless.

Send a request twice as the same person. The second time, the server still greets you like a stranger. HTTP does not remember past requests.

Being greeted anew on a second visit looks a little frustrating. But it was made that way on purpose. Because the server does not have to remember each guest, its work stays light, and it can handle a huge number of requests at once.
In exchange, if the server is to recognize "that person from before," a marker has to travel with every request. That marker is the cookie, which we meet a little later in the lesson on sessions and cookies.

Gathering pieces into one page

A web page does not arrive in a single request. First the browser GETs the document that holds the text and skeleton. Reading it, the browser finds that an image file and a styling file are needed too.
So it sends more requests: give me the image, give me the styling. Only by trading requests and responses several times and gathering the pieces one by one does the page become complete.

Tap each piece to request it. Text, image, and styling arrive as responses, and the page fills in step by step.

With every piece gathered, the empty spots filled in. To our eyes it seems to appear all at once, but it is really the result of many requests and responses: one skeleton, one image, one styling file, each asked for and fetched separately.
A large page can take dozens of such requests, sometimes more than a hundred. The internet is fast enough that it all finishes in the blink of an eye, so we simply feel the page appeared.

Summary

In short: the web moves in request-and-response pairs, and each request carries an action such as GET (fetch) or POST (send). Each response comes with a number that says whether it succeeded or failed.
One page is built by gathering pieces over many requests and responses. And because HTTP does not remember past requests, it treats every request like a first-time guest. This simplicity lets a server handle many requests lightly. That is the agreement called HTTP.

Tap the key points in order to review. (request and response → GET/POST actions → terribly forgetful → gather pieces into a page)

Now you know how web pages travel back and forth. The browser requests and the server responds; that is the basis of the web.
But people's browsers are not the only things that speak HTTP. Programs exchange data over HTTP too, as when a weather app fetches today's forecast from a server. The next lesson covers the API, the counter where one program asks another to do a job. How carts and logged-in states are remembered comes after that, in the lesson on sessions and cookies.