Server response

The second piece of the puzzle is the server. Just like a server at a restaurant, the Web server diligently awaits clients’ instructions. It too speaks the HTTP protocol. When client sends out the verb to the server it is called HTTP request. The job of the server is to respond to each request. You might've seen the response request timeout error in the browser. It appears when the server is so busy and overwhelmed that it cannot respond in the reasonable amount of time. With clients like your browser usually don't wait forever, thus saying timeout as in “I waited and waited but it doesn't respond so I bailed”.

So, a good behaving server sends out an HTTP response back to the client. If everything goes well in the requested thing actually exists, then the response will include a cheerful success message, some rather boring technical information, and, more importantly, the text that the client wanted.

At this point the server completely forgets about the client. It doesn't even try to remember who the client is, what kind of things it's interested in, or whether it's going to request more things. Continuing our analogy with a restaurant, imagine that the waiter is never assigned to a table. You can always raise your hand and ask for something, but every time a new waiter comes. It's completely fine if you are asking for particular things every time, but it requires additional explanation from you if you want to maintain common context. So, if you had a glass of red wine, you can't just ask for another glass. You have to specify a glass of red wine since the waiter has no idea what you had.

As a user you have a different experience. Once you login to Gmail you usually stay logged in for months. The Gmail server does indeed remember you, even after you reload your computer. In order to achieve this illusion of consistency and memory the Web server and a web browser do lots of smart tricks. you will learn these tricks later but for now I encourage you to acknowledge the underlying simplicity of the web. Every single thing that happens in your browser, starting from simple articles on Wikipedia and all the way to interactive web applications, is the result of hundreds and hundreds of primitive requests and responses from an amnesiac.

The final piece of the puzzle is the pipe between the client and the server. As I said before, the Internet is the thing that allows pieces of the web to talk to each other. The client and the server speak HTTP, but the underlying Internet speaks a different protocol. As web developers we don't have to think about this too much, but it's useful to understand that in reality HTTP makes sense only on the ends of the pipe, and while in the pipe requests and responses are wrapped inside a whole different protocol. The cool thing about software engineering and computer science is that it provides lots of abstractions: things that hide the way complex systems and make it so that you only have to think in terms of something that's relevant to you. Just like with paper mail you don't have to think about how your letter goes through multiple stations vehicles and roads, you only have to specify the address and the name of the recipient. Everything else is taken care of and is hidden from you.

So when the client sends the request via the pipe, it thinks about the pipe as a magical portal that goes directly into the server. The server does the same.