#include
s, Part 2
#include
s, Part 1
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 #include
s; 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:
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:
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
Naming Conventions:
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
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
In the next section we will talk about dynamic includes, a topic
many folks ask about!
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.
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.
#include
s.
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.
include
d 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!)
#include virtual
s from
whatever ASP scripts need them.