Report > Server Side Includes (SSI)

Server Side Includes (SSI)

I'm not a Server Side Includes (SSI) wizard. In fact, I have a lot to learn. Fortunately for both of us, SSI are not that complicated.

Before I get into the thick of the report, let me throw you a definition of sorts. SSI are basically a way for you to dynamically add information to your web pages without directly using HTML code. In effect, they give you robust control over your HTML components. So, you can call in information from another source (usually a file with some generic text or HTML coding in it). When the web page is requested, the server reads the HTML file and looks for instructions to perform certain actions (i.e., calling in the extra information you want to include). Then, the page is displayed using normal HTML with the information that the server has been directed to include.

If my definition isn't clear, you'll need to run through a tutorial before you are able to benefit from this report. As I said, SSI are not that complicated, but having a clear definition in mind is important for this report. If you need an introduction, I suggest that you try one of these sources, then head on back to this WebWord.com report:

Six Questions (and Many Answers)

In the Link Exchange Digest #613, Dr. Mani Sivasubramanian asked six excellent questions about server side includes. Dr. Mani was kind enough to share several reader responses with me.

1) What are the downsides of using SSI?

Ivan S. Manida of aGSM.net summed up the biggest problem this way:

Server load increases. Your web server will take some performance hit if your page needs to have SSI tags parsed.

Other folks had similar things to say about the downsides of SSI. Michael Ludwick states that CPU/resources can take a hit, but that this only really applies to big sites (several million page views per day). However, badly designed SSI can really be a problem on even the best systems.

Deacon B. of GenerousNet states that there are some security issues with using the SSI "exec" function (but they are no greater than using CGI). Deacon also reminds us that SSI take more CPU cycles, however, CPU cycles are almost free (it's the bandwidth that costs you).

Overall, the advantages outweigh the costs. As Ivan Manida says you can include any system command result via SSI: date, filesizes, modification times, and so forth. You can configure all kinds of things. In short, you have the power to add information to your pages in a simple, dynamic manner.

2) Does the use of an .shtml extension instead of the usual .htm or .html lead to any confusion in promoting your URL offline?

Note: The assumption of this question is that to use SSI you must use the .shtml extension, which is not true. In any event, no person really thinks that the .shtml is really the cause of problems or user confusions. The .shtml does not make much difference to web users. However, it might cause other problems, particularly for web developers. For example, if you have all .html files, then if you decide to rename your files to use the .shtml extension, you could really mess up your users' bookmarks and various links to your site.

However, I'd like to tell you what Jill Metcalfe had to say about this issue:

You don't need to use the .shtml extension at all. Simply put this line in your .htaccess file: AddType text/x-server-parsed-html .html This means that the server will look for SSI in all files with an .html extension. I use "html" for all files that contain an SSI call and "htm" for non-SSI files. I think that's neater, and less confusing for users.

The bottom line is that you can use a simple and elegant workaround to the .shtml file configuration. Your site can benefit from SSI and your users don't suffer. You can also prevent your site from serving up broken links.

3. Are there any kinds of browsers that cannot support SSI or the .shtml extension? I know some SERVERS don't, but does this apply to browsers too?

Ivan S. Manida of aGSM.net says that as far as he knows this action is completely transparent to the browser. The server includes the text file before the browser sees the include command (at least with Internet Explorer 2.0 and Netscape Navigator 2.0 and above).

Bottom line: I did not find any other good information about this. However, from my understanding of SSI, this should not be a concern for the major browsers. Feel free to send me any problems you have seen using .shtml and SSI with browsers.

Steven Champeon of Hesketh.com wanted me to stress the following point:

SSI has NOTHING to do with the browser. As far as the browser is concerned, it doesn't know whether the file it is displaying was produced on the fly from SSI, PHP, ASP, magic, radio interference, etc. The Content-type header should be the only thing that matters. As long as your server is producing a valid Content-type header, the browser is oblivious to how the files were generated.

4. SSI imports another HTML file into a specified location in the page. When it does so, is it permitted to use JavaScript code and CSS (Cascading Style Sheets) in the HTML file being imported? In other words, does the SSI code import the ENTIRE html file, including the code within the <head> ... </head> tags as well? Or is it limited only to the code within the <body>....</body> tags?

Here's what Jim Foley, The Information Wizard, had to say:

Actually it imports a text file not a html file. So the text file can have anything you wish in it. You don't need the entire html code (i.e., <head> tags and <body> tags), unless that is part of what you want included. You can even have more include statements inside your include file, providing your server supports nested includes, of course.

Ivan S. Manida of aGSM.net says that virtually any information can be used:

Look at SSI like this - servers get a request for the .shtml page, then it gets parsed for SSI tags, and if it finds include tag, the specified file is inserted in place of the tag right away. After that, the page is served. For example, all pages on my site using SSI start with  and then the actual page code follows. All head and body and html tags are in SSI.

Finally, Jill Metcalfe rounds things out. She claims that you don't need any <body> or <head> tags in your imported file, just the html you need for your segment. In fact, some browsers might get confused if they find more than one set of <body> tags in one page. Have a look at the source of one of her SSI footers if you'd like to see that you can pull in what you need without the <HTML> or <body> tags. Further, as a result, the imported segment will inherit any CSS or other instructions given in the head or body of the page into which it is imported. Things end up being transparent.

Deacon B. of GenerousNet says you usually do not want to import extra <HTML> and <body> tags, or some browsers will choke. (I assume that this is because you'll have double entries of <html> in the to-be-displayed file).

5. Is there any point in using specific META tags for the HTML file
being IMPORTED by SSI? Do search engines spider those separately?

Here's Ivan's answer to this one:

I figured that search engines request pages the same way as every client does - via HTTP protocol, so the server parses SSI the same way it's done for clients. Spiders won't note any difference (unless they somehow access your site via FTP)

Jill Metcalfe says that there's a danger that they might, unless you put all your SSI segments into a separate directory and exclude that directory specifically in your robots.txt file, thus: User-agent: * Disallow: /ssi/

Finally, Steven Champeon of Hesketh.com had this to say:

If your SSI directory is open to viewing, and the individual files in it are linked somehow (as opposed to being #included) then, yes, there's a danger, but it has NOTHING to do with SSI, the same site management concern arises for ANY files.

SSIs are parsed on the server and have nothing to do with browsers, and that, according to Steve, is the key.

6. Are there any precautions I need to take about using SSI on my
site?

I'm told that you won't be able to view the page unless your upload them to your site. I suppose you could also set up a dummy HTTP server to try this out, but you might as well just test using the upload method.

Michael Ludwick says:

You have to think of the impact on your server and why you are using them. If it's not dynamic data we tend to just generate the pages from a perl script when needed. If it's not an active site it may not matter.

Michael also says that he would only use the SSI for dynamic data that changed several times a day (or perhaps several times a minute). Anything else could easily be done through cron/perl and save CPU cycles (i.e., computing resources).

Here's what Deakon B. has to say:

Just watch your permissions. If SSI is enabled, and hackers are able to upload files, they can run a command through SSI's "exec" that would, for instance, mail them the host's password file. Also, be careful not to create an infinite loop. For example, if a.shtml says to include b.shtml, and b.shtml says to include c.shtml, and c.shtml says to include a.shtml, you end up with an infinite-size file that never gets sent to the user, but crashes the server instead.

From what I read, you need to be sure that you are careful about your code and syntax. Things need to be written just right.

Books

Neil Kohl of ACP-ASIM Online (American College of Physicians-American Society of Internal Medicine) recommends the following two books:

Web Design in a Nutshell (by Jennifer Niederst, and published by O'Reilly) has a concise chapter on SSI. One weakness is that it doesn't discuss the differences between server implementations --- we had a bit of trouble getting an SSI that worked fine on Apache to work on IIS because of the differences in the way that the "config timefmt" command is implemented.
Another O'Reilly book, CGI Programming (by Shishir Gundavaram) has a slightly longer chapter on configuration and use of SSI's.

Neil also states that Webmonkey has an article on using Apache's SSIs (which were developed by people at Webmonkey who are also working on the Apache project).

WebWord.com Reader Feedback

Malcolm O'Keeffe wrote me to say that Dreamweaver can display SSI files in its visual editing mode, which is great because it saves you the effort of uploading your files to a web server, switching to a browser, and hitting reload each time you make a change. Dreamweaver also supports and can display XSSI information by using an extension written by the folks at Webmonkey.

The End

That's about all I have to say on the matter of SSI for now. If you have questions or comments, throw them at me <john@webword.com>.