Where are we?

We’ve talked about the layers. On the previous page, we looked at HTML, the main technology of the display layers on the Web.

Let’s put the last three pages together. We’ll track a browser’s request for a page through to the server, and look at how the server responds.

We’ll talk about static sites in this lesson. We’ll talk about dynamic sites later. Don’t worry about the differences for now; we’ll get to it.

This lesson’s goals

By the end of this lesson, you should:

• Know that many Web page requests are actually requests for files.

• Know how a URL is mapped to a server file.

The user clicks a link

Suppose that a browser shows this.

Figure 1. Link rendered in a browser.

It comes from this HTML.

<a href="http://doomdogs.com/test.html">Test page</a>

There are two parts to the link. First, there’s the text shown to the user. That’s “Test page.” Second, there’s a URL: http://doomdogs.com/test.html. That’s where the browser will go if the link is clicked.

GETting a page

A user clicks the “Test page” link. What does the browser do?

First, it creates an HTTP GET request. We looked at HTTP earlier, in the lesson on the services layer. The request looks something like this:

GET /test.html HTTP/1.1

The message is sent to a server. Which server? The one given in the URL.

The URL of the desired page is http://doomdogs.com/test.html. The first part – http – is the service-layer communication protocol to use. The second part – doomdogs.com – is the domain name of the server. DNS converts that into an IP address (we talked about that earlier). So that’s where the message is sent: to the computer associated with the name doomdogs.com.

The rest of the URL (/test.html) tells the server what data to return to the browser. That part of the URL matches a file on the server. A server might have 50,000 files that it can send to a browser. /test.html is the particular file it should send.

URL paths and file paths

Let’s look at this more closely.

As you know, the files on the computer you’re using right now – PC, Mac, whatever – are organized into a directory tree. Windows calls directories “folders,” but they’re the same thing. Webers usually talk about directories rather than folders.

Here’s part of the tree on my Windows hard drive.

Figure 2. Directory tree

The Windows path to the file cyril.html is:

C:\xampp\htdocs\animalsofdoom\cases\cyril.html

This is a file path, of which the file name (cyril.html) is just one part.

I can use this path in Windows programs. For instance, I could type the path into the Open File box of a Windows editor:

Figure 3. Windows file path

Other operating systems have different rules for file paths. The same path on a Unix machine might look like this:

/opt/lampp/htdocs/animalsofdoom/cases/cyril.html

Unix (and Linux and similar things) don’t have drive letters, like C: or D:. And they use a / rather than a \ to separate subdirectory names.

Another difference is that Windows file names are not case sensitive, while Unix file names are case sensitive. So, in Windows:

C:\awah\ajer\kyam.txt

and

C:\awah\ajer\Kyam.txt

refer to the same file. But in Unix:

/awah/ajer/kyam.txt

and

/awah/ajer/Kyam.txt

refer to different files.

Web apprentices often forget this. Suppose an apprentice creates a site on a Windows PC. S/he refers to a file as DepressedDoom.html in some places, and depresseddoom.html in others. It works fine, because Windows thinks that DepressedDoom.html and depresseddoom.html are the same file.

The apprentice uploads the site to a Unix server (most Web servers run Unix of some sort), and the site breaks. Unix thinks that DepressedDoom.html and depresseddoom.html are different files. Suppose the file is really called depresseddoom.html on the Unix disk drive. If a browser asks for DepressedDoom.html, the server will return a 404 (file not found) error.

Here’s the rule we’ll be following throughout CoreDogs:

Always use lowercase for file names.

Mapping URL paths and file paths

Notice that file paths and URL paths look similar. There’s a reason for that: they are different versions of the same thing!

A URL is really a file path, with some networkish stuff added.

This is for static sites only. Dynamic sites are different. More later.

How does this work? By taking a directory on a Web server, and making it the root of a Web site.

An example

Let’s look at the process. Here’s Jake, looking at a Web page on doomdogs.com.

Figure 4. Jake finds a ball

Why is Jake’s browser showing him a link? Because it got this HTML:

<a href="/products/ball.html">Bouncing ball</a>

This link says to show the text “Bouncing ball.” If the user clicks on it, then jump to the page /products/ball.html.

So, Jake wants to learn more about the product. He clicks the link.

Here’s what happens.

Figure 5. Serving a file

The page Jake is looking at is on doomdogs.com. When he clicks a link to /products/ball.html, he is really asking for the page doomdogs.com/products/ball.html. The browser and server are using HTTP to talk to each other, so it’s as if Jake typed http://doomdogs.com/products/ball.html into the browser (1 in Figure 5).

The browser creates an HTTP message to doomdogs.com: GET /products/ball.html (2). The Internet sends the message to the Web server.

Let’s assume that doomdogs.com is using the Apache Web server software. It’s the most popular in the world. So, the company DoomDogs has a server computer, and it has the Apache software running on it.

Apache gets the path from the URL: /products/ball.html. Its job is to translate the path in the URL to a path on the computer’s disk drive. But how?

Apache has a configuration file, created by the DoomDog’s Web master. The file tells Apache how to run.

One of the settings in the file is DocumentRoot. The setting tells Apache where on the computer’s disk drive the files for the Web site are stored. The Web master put all the data for the doomdogs.com Web site in the directory /sites/dd. Then s/he set DocumentRoot to /sites/dd, so that Apache would know where to get the files.

The server takes its DocumentRoot setting (/sites/dd) and appends the URL path (/products/ball.html), giving /sites/dd/products/ball.html (3 in Figure 5). This gives the file path to the page the browser asked for. Apache has translated the URL to a file path on the server computer’s disk drive.

Apache reads the file (4), and sends its contents back to the browser (5). The browser renders the content for Jake (6).

Hooray! Jake is happy, and runs around and barks.

Summary

In this lesson, you learned:

• That many Web page requests are actually requests for files.

• How a URL is mapped to a server file.

What now?

Let’s put some of this knowledge into action. Time to buy a Web hosting account, and get real!