What is a webserver?

When you click on a link in your browser, you are making a request for something — technically, a resource — on the web.

A webserver is the computer (or, more accurately, the program running on that computer) that responds to your request and sends the right thing back: a web page, and image, or something else. Together, all the webservers in the world, listening for requests on the public internet and sending back responses, form the world wide web.

For this to work, all the webservers and all the devices and programs making requests (clients) need to agree on how those requests and responses are made. This is the Hypertext Transfer Protocol (HTTP). This is why you see http at the start of web URLs.

The webserver listens for requests to arrive, and responds with the appropriate content, together with a status code. For example: 200 means "OK, here's what you requested", but 404 means the request was for something the webserver doesn't have. Those numbers and their meanings are defined in the protocol — they are the HTTP status codes.

Webservers don't care about routing

The web works because the requests and responses get delivered to the correct places — the right webserver, or your browser. But that's not the webservers' problem. That's the job of internet routers, IP addresses, and the domain name system.

The webserver's job is to listen out for requests, and send a response back for each one.

Webserver as a file server

The animated diagram below shows the simplest (and very common) case of a browser making a request for a static web page. The webserver in this example has the contents of the page as three files stored in its "server root" — a directory called htdocs. In the demo, each request the browser sends in is for one of those files. For each request, the webserver needs to find the file, read it, and return its content as the response.

The first request is the for the webpage cat.html.

Some things to notice

The browser doesn't know (or care) about the name of the directory the webserver is using to store the information. It's called the "server root" because it's effectively the root directory of the webserver. In fact there will be many other directories below that one — so it's not the root directory of that machine's file system. But when the websever looks for the file requested, it only looks inside the server root (and any directories it contains).

URLs often look like file paths because sometimes that's exactly what they are: paths through the filesystem starting at the server root. But as you'll discover in your Buggy Editor, in practice there are good reasons why it doesn't always work this way.

The browser is sending GET requests (that is, the HTTP method is GET) because it's just asking to get the resource (HTML page, stylesheet, or image file). But there are other types of request method. For example, your Buggy Editor uses the POST method when a request is sending ("posting") data to the server.

This is static content

This example shows static content: the server did not modify the contents of the three responses (the HTML page, the CSS, and the image of the cat) in any way, and in fact they were prepared before the request was sent. There is a separate tech note about static versus dynamic content, and you need to understand that in order to appreciate how your Buggy Editor works differently.

Two important differences with your Buggy Editor

Your Buggy Editor is a webserver, but it's behaving differently from this static example in two important ways.

• the content it's serving isn't always static (in fact... it's often not in a file): see the tech note How Flask works as a webserver, which is the follow-up to this one
• it's usually not connected to the internet: instead it's running on localhost see this tech note about using localhost