Chapter 1

CHAPTER 1
Active Server Pages:
An Introduction

ASP is a technology that allows you to dynamically generate browser-neutral
content using server-side scripting. The code for this scripting can be written in
any of several languages and is embedded in special tags inside the otherwisenormal
HTML code making up a page of content. This heterogeneous scripting/
content page is interpreted by the web server only upon the client’s request for
the content.
To understand the evolution of ASP and its current capabilities, it helps to quickly
review the history of web-based content and applications.

The Static Internet
In the early days of the World Wide Web, all information served to the client’s
browser was static. In other words, the content for page A served to client 1 was
exactly the same as the content for page A served to client 2. The web server did
not dynamically generate any part of the site’s contents but simply served requests
for static HTML pages loaded from the web server’s file system and sent to the
requesting client. There was no interactivity between the user and the server. The
browser requested information, and the server sent it.

Although the static Internet quickly evolved to include graphics and sounds, the
Web was still static, with little interactivity and very little functionality beyond that
provided by simple hyperlinking.

Figure 1-1 illustrates the user’s request and the web server’s corresponding
response for static (HTML, for example) web content.

The Dynamic Internet Part I: CGI Applications
One of the first extensions of the static internet was the creation of the Common
Gateway Interface. The Common Gateway Interface, or CGI, provides a mechanism
by which a web browser can communicate a request for the execution of an
application on the web server. The result of this application is converted/formatted
into a browser-readable (HTML) form and sent to the requesting browser.

CGI applications raised the bar on what was expected from a web site and transitioned
the World Wide Web from an easy way to share information to a viable
platform for information processing. The response to this evolution of the Web
was rapidly accelerated growth and the beginning of the business world’s interest
in the Internet.

Part of this growth was the creation of several client-side scripting solutions that
enabled the client’s machine to take on part of the processing tasks. Chief among
these client-side solutions are Netscape’s JavaScript and Microsoft’s VBScript.
During this huge growth in Internet-based technologies, Microsoft released its
Internet Information Server. Touted as being easy to use, scalable, portable,
secure, and extensible, it is also free and closely integrated with Microsoft’s
Windows NT operating system. It quickly became very popular.

The Dynamic Internet Part II: ISAPI
In addition to supporting the CGI specification, Microsoft introduced an alternative
to CGI, the Internet Server Application Programming Interface (or ISAPI).
ISAPI addresses one of the most limiting features of CGI applications.
Each time a client requests the execution of a CGI application, the web server
executes a separate instance of the application, sends in the user’s requesting
information, and serves the results of the CGI application’s processing to the client.

Figure 1-1: Static web content: request and delivery
Browser Server
Browser requests Sample.HTM
from Web Server
Browser Server
Server sends Sample.HTM
to browser from file system

The problem with this approach is that a separate CGI application is loaded for
each request. This can be quite a drain on the server’s resources if there are many
requests for the CGI application.
ISAPI alleviates this problem by relying on dynamic link libraries (DLLs). Each
ISAPI application is in the form of a single DLL that is loaded into the same
memory space as the web server upon the first request for the application. Once
in memory, the DLL stays in memory, answering user requests until it is explicitly
released from memory. This increased efficiency in memory usage comes at a cost.
All ISAPI DLLs must be thread-safe so that multiple threads can be instantiated into
the DLL without causing problems with the application’s function.*
ISAPI applications are normally faster than their equivalent CGI applications
because the web server does not have to instantiate a new application every time
a request is made. Once the ISAPI application DLL is loaded into memory, it stays
in memory. The web server does not need to load it again.

In addition to ISAPI applications, ISAPI allows for the development of ISAPI filters.
An ISAPI filter is a custom DLL that is in the same memory space as the web
server and is called by the web server in response to every HTTP request. In this
way, the ISAPI filter changes the manner in which the web server itself behaves.
The ISAPI filter then instructs the web server how to handle the request. ISAPI
filters thus allow you to customize your web server’s response to specific types of
user requests. To state the difference between ISAPI filters and ISAPI applications
(and CGI applications) more clearly, ISAPI filters offer three types of functionality
that set them apart from ISAPI (or CGI) applications:

• An ISAPI filter allows you to provide a form of web site or page-level security
by its insertion as a layer between the client and the web server.
• An ISAPI filter allows you to track more information about the requests to the
web server and the content served to the requestor than a standard HTTP
web server on its own can. This information can be stored in a separate format
from that of the web server’s logging functions.
• An ISAPI filter can serve information to clients in a different manner than the
web server can by itself.
Here are some examples of possible ISAPI filters:
• A security layer between the client and the web server. This security layer
could provide for a more thorough screening of the client request than that
provided for by straight username and password authentication.
• A custom filter could interpret the stream of information from the server and,
based on that interpretation, present the stream in a different format than
would the original web server. The ASP.DLL (see the following section) is an
example of this type of ISAPI filter. It interprets the server code in a script
requested by the client and, depending on its interpretation, serves the client
customized content according to the client’s request.
* The latest version of Microsoft Internet Information Server 4.0 allows you to load CGI applications
into the same memory space as the web server, just as you can ISAPI applications.
• A custom filter could map a client’s request to a different physical location on
the server. This could be used in high-volume sites where you might want to
move the client onto a different server.

Active Server Pages and Active Server Pages 2.0
Late in the life of Internet Information Server 2.0, Microsoft began public beta
testing of a technology whose code name was Denali. This technology is now
known as Active Server Pages and is a very important aspect of Microsoft’s
Internet Information Server strategy.

This ASP technology is encapsulated in a single, small (~300K) DLL called ASP.DLL.
This DLL is an ISAPI filter that resides in the same memory space as Internet Information
Server. (For more about how IIS is configured to use ISAPI filters, see
Appendix C, Configuration of ASP Applications on IIS.) Whenever a user requests
a file whose file extension is .ASP, the ASP ISAPI filter handles the interpretation.
ASP then loads any required scripting language interpreter DLLs into memory,
executes any server-side code found in the Active Server Page, and passes the
resulting HTML to the web server, which then sends it to the requesting browser.
To reiterate this point, the output of ASP code that runs on the server is HTML (or
HTML along with client-side script), which is inserted into the HTML text stream
sent to the client.
* Figure 1-2 illustrates this process.

ASP: A Demonstration
The actual interpretation of the web page by the ASP.DLL ISAPI filter is best
explained by example. Example 1-1 shows a simple active server page, Sample.
ASP. In this example, three pieces of server-side code, indicated in boldface, when
executed on the server, create HTML that is sent to the client. This is a quick introduction.
Don’t worry if you don’t understand exactly what is going on in this
example; the details will be explained in Chapter 2, Active Server Pages: Server-
Side Scripting.
* Note, however, that an Active Server Page application could just as easily send XML, for example
to the browser. HTML is only the default.

Figure 1-2: Dynamically generated web content: request and delivery
Example 1-1: Sample.ASP, an Example of Processing Server-Side Script
<%@ LANGUAGE="VBSCRIPT" %>
<HTML>
<HEAD>
<TITLE>Sample ASP</TITLE>
</HEAD>
Browser Server
Browser requests Sample.HTM
from Web Server
IIS passes requested
document to ASP.DLL
Browser Server ASP passes the interpreted
(new HTML) back to IIS
for sending to the client
Browser
Server
IIS sends Sample.HTM to the client

When the client receives the HTML result from the ASP script’s execution, it resembles
Figure 1-3.
<BODY>
Good afternoon. 
Welcome to the sample. It is now approximately
<%=Time()%> at the server. Here are a couple of
demonstrations: 
Some simple text formatting done using HTML: 
Hello Size 1 
Hello Size 2 
Hello Size 3 
Hello Size 4 
Hello Size 5 
 
The same text formatting using server-side code: 
<%
For intCounter = 1 to 5
%>
>
Hello Size <%=intCounter%> 
<%
Next
%>
 
</BODY>
</HTML>
Figure 1-3: Client-side view of Sample.ASP

If you were to view the HTML source behind this HTML, you would see the
output in Example 1-2.
The server accepted the request, ASP.DLL interpreted and executed the server-side
script and created HTML. The HTML is sent to the client, where it appears indistinguishable
from straight HTML code.
As mentioned earlier, you will learn more about server-side scripting and how it
works in Chapter 2.

The ASP Object Model
ASP encapsulates the properties and methods of the following six built-in objects:
• Application
• ObjectContext
• Request
• Response
• Server
• Session
Example 1-2: Sample.HTM, the Output of Sample.ASP
<HTML>
<HEAD>
<TITLE>Sample ASP</TITLE>
</HEAD>
<BODY>
Good afternoon. 
Welcome to the sample. It is now approximately
9:28:47 at the server. Here are a couple of
demonstrations: 
Some simple text formatting done using HTML: 
Hello Size 1 
Hello Size 2 
Hello Size 3 
Hello Size 4 
Hello Size 5 
 
The same text formatting using server-side code: 
Hello Size 1 
Hello Size 2 
Hello Size 3 
Hello Size 4 
Hello Size 5 
 
</BODY>
</HTML>

These objects are part of the ASP.DLL and are always available to your ASP
applications.

The Application object represents your ASP application itself. This object is
universal to all users attached to an application, and there is only one Application
object for all users. The Application object has two events, Application_OnStart
and Application_OnEnd, that fire when the first user requests a page from your
application and when the administrator explicitly unloads the application using the
Microsoft Management Console (see Chapter 4, Application Object), respectively.

The OnStart event can be used to initialize information needed for every aspect of
the application. The OnEnd event can be used to do any custom cleanup work
after the end of your application. You can store any variable type (with some limitations
—see Chapter 3, Extending Active Server Pages) with application-level
scope. These variables hold the same value for every user of the site. See
Chapter 4 for more information on the Application object.

In this book, an ASP application is a group of scripts and HTML content
files that together form some function.

The ObjectContext object is actually part of the Microsoft Transaction Server and is
only interfaced through ASP. The ObjectContext object allows you to create transactional
Active Server Pages. The functions in these pages that support transactions
will succeed as a single unit or fail completely. If your application requires the use
of functions that do not natively support transactions (notably file access), you
must write custom code to handle success or failure of these functions. See
Chapter 5, ObjectContext Object, for more information.

The Request object represents the way you interact with the client’s HTTP request.
This is one of the most important objects in the ASP object model. It is through the
use of the Request object that you access both HTML form-based data and parameters
sent over the address line. In addition, you can use the Request object to
receive HTTP cookie information and client certificate information from your
users. Finally, the ServerVariables collection of the Request object gives you access
to all the information in the HTTP request header. This information contains (in
addition to the cookie information) other relevant data describing the client
machine, its connection, and its actual requests. The ServerVariables collection is
equivalent to environment variables in traditional CGI applications. See Chapter 6,
Request Object, for more information.

The Response object represents your access/control over the HTTP response sent
back to the user. Through the Response object, you can send cookies to the client
and set if and when content should expire. In addition to this, the Response object
is your route to completely controlling how data is sent to the client. Is it buffered
before sending? Is it sent as it is constructed? Finally, the Response object allows
you to seamlessly redirect the user from one URL to another. See Chapter 7,
Response Object, for more information.

The Server object gives you access to the web server itself. This object contains
many utility features that you use in almost every application. Through the Server
object, you can set the timeout variable for your scripts (how long the web server
will attempt to serve a script before serving an error note instead). You also can
use the Server object to map a virtual path to a physical path or encode information
for sending over the address line. The most important method of the Server
object, however, is its CreateObject method, which enables you to create instances
of server-side components. You will use this method any time you require functionality
outside that provided by the built-in objects. Database access, for
example, is handled by various ActiveX Data Objects that must be instantiated on
the server before being used. See Chapter 8, Server Object, for more information.
Finally, the Session object holds information that is unique to a specific user’s
current session on the web server. Each user session is identifiable through the use
of a unique cookie that is sent to the user every time the user makes a request.
The web server starts a session for every new user that requests a page from your
web application. This session stays active by default until 20 minutes after the
user’s last request or until the session is explicitly abandoned through code. See

Chapter 2