The Gritty Details:
Did you know that included files can include files themselves? If you want to confuse someone, you just need to make several include files include other include files, then make the comment: "Hey, Bob, in Report.asp, did you want the file included by the include to include stats.asp, which includes another included file, or do you want Report.asp not to include any included files that include included files?" OK, while that might not make much sense, it sure does sound cool.

The only limitation for including files in included files, is that included files can't include the file that included them! (Now that sounds really cool!) This means you can't perform circular includes. FileA.asp can't include FileB.asp if FileB.asp includes FileA.asp. If you try to do this you will get an error message.

You may be wondering what kind of files can include other files? There's no real magic to it, any file extension can be setup to use SSI. By default, files with the following extension can perform server-side includes: .asp, .stm, .shtm, and .shtml. You can create your own types, though. For example, say we wanted to have files with the extension .scott have SSI enabled. Well, first things first, we'd set up a MIME type of text/html for .scott files. This would be done through the Internet Service Manager, by right clicking on the machine name, clicking Properties, and then clicking the File Types button under the Computer MIME Map section. Next you'd click New Type, and create a new MIME type of text/html for files with the .scott extension. Note that on the right you can see a new MIME type for .scott files!

Next, you will need to associate .scott files to be parsed with ssinc.dll before being passed onto the client. To do this, in the Internet Service Manager, right click on your Web Site, and click on Properties. Go to the Home Directory tab, and click on the Configuration button. The first tab, App Mappings, is the tab you want to stay on. Click Add, and associate .scott files to be processed by C:\WINNT\System32\inetsrv\ssinc.dll. (The exact directory name may differ on your webserver.) That's all there is to it! Now, you can create a file named test.scott, and place a #include inside of it. Pretty darn neat, eh? There is one more thing you need to make sure you do. Files that use SSI must be put in a directory with Script or Execute access permissions. These permissions can be set on a directory-by-directory basis through the Internet Service Manager.

If you want to get rid of SSI altogether, you just need to remove the entry in the App Mappings table. For example, say you only wanted to have .stm pages perform server-side includes, but not .shtm or .shtml. You'd just to need to visit the App Mappings tab in the Internet Service Manager, click on the .shtm and .shtml extensions, and click the Remove button.

Behind the Scenes...
Wondering what's happening behind the scenes, how the file is properly included? Well, I do too! So, I regret that I cannot inform you exactly what's happening. However, I can take an educated guess at it. Whenever a file is requested of .stm or .asp or .scott (or any type that is associated with ssinc.dll), the file is parsed first by ssinc.dll. This DLL looks for #includes; if it finds one, it opens the file you want included, and parses that file through ssinc.dll. Once ssinc.dll has finished parsing all the files, it passes back the resulting content to IIS, which then, depending on the extension, does other things with it. If the file is of a MIME type of text/html, the results from ssinc.dll are sent to the client. If the file has a .asp extension, asp.dll does some work on it. That's my wager. If you know, for sure, what's happening behind the scenes, and have solid documentation on it, please let me know! :)

What I do know is that all SSI directives are performed before the ASP Script is parsed. This means that you can include files with ASP Script in them, and the ASP Script in the included files will be parsed by asp.dll. The drawback to using this method, though, is that dynamic includes are not possible.

Benefits of Server-Side Includes:
So, now that you know how to include files, let's talk about why we should want to include files and what naming conventions we should use. To fully understand the benefits of including files, it's imperative that you understand and agree with Scott's Axioms of Programming. Well, all you have to really do is understand and agree with Axiom 1 and 2:

Axiom 1, of Scott's Axioms of Programming:
Writing more code leads to more bugs, which leads to a longer development cycle, which leads to higher costs. Therefore, a minimalistic approach should be taken to writing code.

OK, so it's not profound or anything, but it's important to know. One way to write less code is to reuse our existing code. This takes us to Axiom 2:

Axiom 2, of Scott's Axioms of Programming:
The longer a piece of code is used, the fewer bugs it contains. The more you reuse existing code, the more you ensure that the code is bug free. The only bug free code is old code.

Using server side includes grant us these two advantages: we ending up writing less code and reusing existing code. This leads to fewer bugs, reduced costs, and fewer headaches. These are the two main reasons we should want to use #includes.

Naming Conventions:
According to Microsoft, "it is good programming practice to give included files an .inc extension to distinguish them from other types of files. While I agree that a naming convention is a good thing, I disagree that a .inc extension is the best thing to use. Why? When files that you include exist within your Web site's directory structure, when a client requests the page, the same rules are applied as any other web page. So, if you give your include files a .inc extension, if someone correctly guesses the name of your include file, they can simply type it into their browser and download the file.

Don't believe me? How would you like to download a copy of ADOVBS.inc from ActiveServerPages.com? Go ahead, do it! :). While downloading ADOVBS.inc is not big deal, you might have code you want to protect. If someone happens to stumble upon the right filename, you could loose the privacy your include files once had. For this reason, I suggest using a .ASP extension. This way, if someone does guess the include file name, IIS will process all the ASP script in the include file before sending it to the client, just like when someone requests a normal .ASP page.

In fact, you can run into grave problems by using non-.asp extensions for your included scripts! A potential security flaw exists when using buggy code in include files, which can reveal your ASP source code to the entire world! (Read Security Alert - Using includes Improperly from non-Debugged ASP Pages can allow Visitors to View your Source Code to learn more!)

One convention I do strongly suggest is to create an include directory, such as /inc or /scripts. You should put all of your commonly used include files here, and then use #include virtuals from whatever ASP scripts need them.

In the next section we will talk about dynamic includes, a topic many folks ask about!