"Server-side includes" (or "SSI") are a fancy name for a technique which, in its simplest and most common usage, allows you to reuse content in multiple places, for example multiple webpages, without having to store or change it in more than one place.
For example, say I have a website whose layout has a vertical navigation bar on the left. The bar and all its links are identical on every page. If I store the HTML for the navigation bar on every page on my site, I have to change every single page individually, every time I want to add or change a link. However, if I can store the HTML for the navigation bar in one place, one file, and reference it every time I want to stick in a page, my life gets much simpler.
In order to explain how SSI works, I'm going to explain a little bit about what happens when you're browsing the Web and click on a link, first with a normal run-of-the-mill webpage (such as those you have probably created yourselves, with extension .html or .htm) and then with a page that uses SSI (.shtml or .shtm). This is a bit of the technical side of the Internet. You don't need to know this by heart, but it helps to understand how to use SSI if you know a little bit of what's happening behind the scenes.
When you click on a link to a simple webpage (for example http://students.washington.edu/lbmelton/workshops/ssi/ssi.html), your computer contacts the server computer on which the webpage resides and asks politely for the page. The server says "OK, here it is" and delivers the file to your computer, which then displays it to you. (By the way, this "conversation" between computers follows a very strict set of rules, known as a "protocol." This specific protocol is known as the "HyperText Transfer Protocol" or "HTTP," which is why those letters prefix URLs. They tell your computer how it's supposed to talk to the server.)
This is called the client-server relationship. Librarians can think of it in terms of a reference transaction, except that there's no interview. The patron (client) requests information, and the librarian (server) fills the request. If the request is badly formulated, the server just says "I don't understand, speak my language or go away."
The file-serving process is only slightly different with SSI. Your computer requests the file from the server. The server locates the file but doesn't simply deliver it; instead, it notices the special ".shtml" extension and knows that it has to do some more processing. It reads through the file, looking for further directions, follows them (for example, inserting another file at a specified place), and then serves it up to the client computer.
As I said, you don't need to know all this perfectly. The important thing to understand is that the web server is what does the work in SSI, the file's .shtml extension is what tells the server it needs to read the file, and the directions in the file tell it exactly what to do. This means that the effects of SSI will not be visible if you open a local copy of your .shtml file in a browser; you have to put it on the server first.
What you need to get started:
We've got all three right here!
Step-by-step, this is what we will do:
<!--#include file="congrats.txt"-->
Now I'll explain just what it is that you put in your file.
First, don't confuse SSI with HTML. HTML markup is what your browser reads and displays in pretty ways. SSI commands are what the webserver looks for in a .shtml file and follows, usually altering the file that is eventually passed to the client.
Let's take another look at the code:
<!--#include file="congrats.txt"-->
If you're familiar with HTML, you'll notice that the blue bits, <!-- and -->,
are HTML comment tags. Anything between these tags gets ignored when a browser
displays this page. This means that if you open a .shtml file on your own
computer, where no webserver has altered it, the raw code of this directive
won't show up. Try it!
The green part, #include,
comes right after the opening comment tag. It is extremely important that
there be no space between the hyphen and the hash; otherwise it won't work.
(This can be an effective way to turn off the SSI should you want to.) The
hash (#) tells the server
that this is an SSI command, not a normal HTML comment, and that it should
pay attention. The keyword include tells
it that the function it's performing is an "include," or what you
might think of as an insertion.
The purple part, file="",
tells the webserver it's going to be including a file. The red part, congrats.txt,
is the name of the file to include. Because there is no other information
about what directory to look in, the server will look for the file in the
same directory or folder as the .shtml file. (If you are familiar with relative
vs. absolute links in webpages, this is the same concept.)
Taken all together, those 35 characters tell the webserver to substitute them (the SSI directive) with the contents of a file named congrats.txt which it should find in the same directory.
Note that if you mistype the name of the file, move the file, rename it, or otherwise break the SSI directive, the server will insert a line of text saying "could not find..." instead of failing silently.
I hinted in the first sentence of this page that SSI was more than fancy cut-and-paste. It can do lots of things, such as inserting the current date/time, a file's last-modified date, or executing scripts. Here's a list of further tutorials and other resources, in order from least to most technical.
Keep in mind that pages written for specific institutions may have directions that apply only to that institution (for example, the page on Carleton University's site has some directions about .htaccess configuration which are unnecessary on UW's servers).
[Disclaimer: other people may use some of these terms differently, such as webpage and website. Neither meaning is necessarily wrong. These are our definitions.]