Server Side Includes

Very often in a web site, there is repeated material on each page. For example, each of the lecture pages in this course have a "footer" that includes copyright license, an icon about the AnyBrowser campaign, and links to an HTML and an CSS tool. Or, perhaps you have a navigation bar or a banner or something else that you want to appear on all or many pages of your site.

You certainly could copy/paste it to each page, but that makes maintenance very difficult: if you decide to change the common content, you have to edit every page, and you have to make sure you don't miss any and that you edit them all in the same way. For a small website, this is bad, but for a large website, this is unreasonable.

A solution is to break your page into pieces, each stored in different file, and have the server cobble them together whenever it responds to a request for your web page. This technology is called a Server Side Includes or SSI. Exactly how to use it depends on the server software. On Puma, we use Apache to serve web pages. For more detail, you can read a Apache tutorial on Server Side Includes.

Suppose we have three pages, A, B, and C, all of which should share a common header and footer, each of which is in a separate file. These shared pieces will be included into the main pages.

• A.html
• B.html
• C.html
• header.html
• footer.html

In the source code of the files A, B, and C, we put a special marker, called a directive, that the server will look for and replace with the contents of the included files. The directive looks like an HTML comment, so that if the SSI doesn't happen at all, the directive won't otherwise mess up your code. Let's look at what page A's source code looks like:

<!--#include virtual="banner.html" -->

<p>Here is some content that is unique to page A of the web site.

<!--#include virtual="footer.html" -->

The text in quotes after the word "virtual" is a relative URL for the file to be included at that point in the main file.

Note that if you "View Source" on A.html, you won't see these directives. Instead, you'll see the included content. The server obeys the directives and constructs the page from the parts and sends it out, and the browser has no way of knowing what the original collection was, or even that SSI was involved at all. SSI is completely invisible.

The server has to do additional work to scan for these SSI directives, and so to avoid doing this for every file, the file has to be marked somehow. On Puma, we do this by making the file excutable.

Making a File Executable

All reasonable FTP clients will be able to change the permissions of a file on the server, though sometimes you may need to poke around a bit to learn how, since it's not the most common of commands.

Fetch

1. Go to the folder that contains the file whose permissions you want to change.
2. Click once on the file to select it
3. Click on the Get Info button or use the menu item "Remote > Get Info". This will pop up an "info" window about that file.
4. In the lower part of the window, you'll see "Ownership and Permissions" click the checkboxes next to all three of the "Execute" labels, and then apply the changes.

WinSCP

This is similar to the directions for Fetch:

• Go to the folder that contains the file whose permissions you want to change.
• Either right click on the file and choose "Properties" (F9) or click once on the file to select it and use the menu item "Files > Properties". This will pop up a window about that file.
• Click on all the checkboxes next to the letter X, the click OK.

In WinSCP, unlike Fetch, you can see the permissions in the "Rights" column of the display. It looks much like the permissions list above.

Bugs

If you make a mistake in your relative URL, you'll see something like the following in your main file, when you view it on the web:

  [an error occurred while processing this directive]

I intentionally put one of these in C.html, so that you can see what it looks like.

1. This work is licensed under a Creative Commons License
2. 
3. 
4. 
5.