What a web server is

A web server is a program that takes an HTTP request and answers with a ready file or an application’s result. The best known are Apache, nginx and Caddy.

Between the browser and the file

You know that a browser asks a server for a page, and you know how it finds the server’s address. Now let’s see who sits at the other end. The word “server” is misleading: it names both the computer in a data center and the program that runs on it. We need the program: the web server.

Its job looks like this. It listens on a port (80 for HTTP, 443 for HTTPS) and waits for connections. When a request comes in, it reads it (the method, the path and the Host header you met in the lesson on HTTP), decides what to answer, and sends the response with a status code. Most often “what to answer” means one of two things: take a ready file from a disk, or ask an application that builds the page for this request. This whole part of the course is about those two choices.

Three servers to begin with

• Apache HTTP Server (since 1995) is the oldest. In the 1990s it was a synonym for “web server”, and it still runs much of the “shared hosting” where you pay a few pounds a month and get a folder for your files. It’s flexible: settings can go into a .htaccess file right in the site’s folder and take effect without a restart. The price of that flexibility is speed when a great many visitors arrive at once.
• nginx (pronounced “engine X”, since 2004) was made in Russia by Igor Sysoev for the Rambler portal, to cope with tens of thousands of simultaneous connections. It’s more economical than Apache and excellent at serving files, and it became the standard reverse proxy: it’s put in front of applications. Today it’s one of the most widely used servers in the world (W3Techs and Netcraft publish current figures, and the Wikipedia article in the sources summarizes them). It has forks too, such as the Russian Angie.
• Caddy (since 2015) is written in Go and wins people over with simplicity: a short settings file, and it gets and renews the HTTPS certificate by itself. For a small project it’s the easiest start.

There are others (IIS from Microsoft, LiteSpeed), but the principle is the same everywhere and the configs look alike. Learn to read one and you can read the rest.

What a config looks like

A server behaves as its config says: a text file of rules. Here is a complete example for nginx. It’s small, and every line reads like plain English.

server {
    listen 80;                      # listen on port 80
    server_name example.com;        # for a site with this name (from the Host header)
    root /var/www/site;             # where the site's files are
    index index.html;               # what to serve at the address "/"

    error_page 404 /404.html;       # a page of our own for "not found"

    location = /old-page {          # one exact address
        return 301 /services.html;  # moved here for good
    }

    location /api/ {                # everything that starts with /api/
        proxy_pass http://127.0.0.1:3000;   # pass it to the application
    }

    location / {                    # all other addresses
        try_files $uri $uri/ =404;  # a file? a folder? otherwise 404
    }
}

The key word is location: a rule for an address. With the exact sign = it matches only one address; without it, it matches every address that begins with it, and when several match, the longest match wins. Inside a rule come the actions: return 301 answers with a move, try_files looks for a file in order and puts =404 last, and proxy_pass hands the request to an application.

Try it: change the config and ask for different addresses. The diagram works out the answer from these rules and names the rule that fired.

Config (you can edit it) server { listen 80; server_name example.com; root /var/www/site; index index.html; error_page 404 /404.html; location = /old-page { return 301 /services.html; } location /api/ { proxy_pass http://127.0.0.1:3000; } location / { try_files $uri $uri/ =404; } }

Restore the example

Files on the disk, in the site’s folder: index.html, services.html, contact.html, 404.html

GET /GET /services.htmlGET /contact.htmlGET /old-pageGET /no-such-pageGET /api/itemsGET /services.html/

404 Not Found

Content-Type: text/html

The rule that matched: location /.

The error page /404.html was sent, with status 404.

This is a model. Real nginx understands many more directives, and its way of choosing a rule is subtler. Only what the lesson needs is here.

Check yourself: why does try_files end with =404?

So that an address that doesn’t exist gets an honest “not found”. Without it the server might send the home page, or an empty response with the code 200, and both the visitor and the search engine would be misled.

The reverse proxy

An application (more on it in the next lessons) usually listens on a port of its own, and it isn’t done to expose it straight to the internet. In front of it stands a server called a reverse proxy: it takes requests from the network, forwards them to the application, receives the answer and hands it to the visitor. It’s “reverse” because an ordinary proxy works on the visitor’s side and hides the visitor, while this one works on the site’s side and hides the site.

Why have such a go-between:

• it accepts HTTPS: the certificate and the encryption live in one place, and the application receives an already decrypted request;
• it serves images, styles and scripts itself: sending a ready file costs it many times less than running the application;
• it compresses responses and caches what can be cached;
• it shields the application from slow clients and from excess requests;
• behind one address it can keep several applications.

If there’s no application and the site is static, no proxy is needed: the server hands out the files itself.

Practice

You’re on a site from 1996. Back then a site was a folder of files, and the server handed them out as they were. Imagine that your project’s pages sit in such a folder. You need to give each section an address of its own, set up a “not found” page with an honest 404 code, and make a move from an old address to a new one with the code 301.

There’s no real server in the sandbox, so you write the config as text and test it in the diagram above, and afterwards you can use it almost unchanged. Paste this scaffold at the end of the page (before </body>):

<section data-scaffold id="server">
  <h2>The site’s server</h2>
  <table>
    <tr><th>Section</th><th>Address</th><th>File</th></tr>
    <tr class="route"><td>First section</td><td class="url">…</td><td class="file">…</td></tr>
  </table>
  <pre id="conf">…</pre>
  <p id="role">…</p>
</section>

Add table rows so that there’s one for each section of your brief, and replace every …. There’s nothing magic in data-scaffold; it’s just a mark for the course, and the block won’t end up in the site you download.

What was wrong with 1996

In 1996 a site really was a folder, and often nobody configured the server at all. The “not found” page was the default gray one with technical English on it, old addresses simply stopped working, and links to them led nowhere. The same page opened with and without www, and search engines counted it as two different pages. Server errors gave away the version of the program and even paths on the disk, which were better hidden.

What stays true is the main thing: every address should have a clear answer. What is new is that today ten lines of config are enough for it, and every one of them can be seen and read.