ASP (Active Server Pages)

Active Server Pages (ASP), retroactively known as Classic ASP after the arrival of ASP.NET, is Microsoft’s original server-side scripting environment for the Internet Information Services (IIS) web server. First released in December 1996, ASP let developers embed VBScript or JScript directly inside HTML files using <% and %> delimiters; IIS executed that code on each request and returned the resulting markup to the browser. For roughly six years it was the dominant way to build dynamic web applications on Windows, and it established conventions — request and response objects, session state, server-side includes of reusable code, database access through a standard object library — that carried forward into ASP.NET and influenced the wider web development world.

History & Origins

Aspect Software Engineering

The technical lineage of ASP begins outside Microsoft. Aspect Software Engineering, founded in 1991, built database-to-web middleware; its flagship product, dbWeb, exposed information stored in databases to web servers without requiring the developer to write CGI programs. Microsoft announced its acquisition of Aspect in 1996, stating that it intended to fold the technology into its Internet tools to strengthen their database query capabilities. Aspect’s engineers and their tooling are generally credited as the nucleus of the team that produced Active Server Pages.

Denali and the Active Platform

The project was developed under the code name Denali. Microsoft publicly outlined it as part of the broader “Active Platform” strategy at its Site Builder Conference in the fall of 1996, and shipped ASP 1.0 that December as an add-on for IIS 3.0 on Windows NT 4.0.

The timing mattered. In 1996, dynamic web content on most platforms still meant CGI: a separate process forked per request, typically a Perl or C program that wrote HTML to standard output. ASP inverted the model. Rather than a program that emitted a page, an ASP file was a page with islands of code inside it, and the scripting engine ran in-process with the web server. That combination — an HTML-first authoring model plus in-process execution — was the technology’s central bet, and it proved to be the right one. PHP (which evolved independently over the same period), JSP, and eventually ASP.NET all converged on the same basic shape.

Maturity and Succession

ASP 2.0, released in 1997 with IIS 4.0 in the Windows NT 4.0 Option Pack, formalized the built-in object model and integrated with Microsoft Transaction Server for distributed transactions. ASP 3.0 arrived in 2000 with IIS 5.0 in Windows 2000, adding Server.Transfer and Server.Execute for server-side page dispatch and the ASPError object for structured error handling. ASP 3.0 was the last version: in early 2002 Microsoft shipped ASP.NET 1.0 with the .NET Framework, and active development of Classic ASP ended. Crucially, ASP.NET was designed to run side by side with ASP in the same IIS installation, which allowed incremental migration rather than forcing a rewrite — a decision that let a great many ASP applications survive by simply never being migrated at all.

Design Philosophy

ASP was built around a small number of pragmatic commitments:

• The page is the unit of work. There is no controller layer, no routing table, and no application framework. A URL maps to a file, and the file is executed top to bottom.
• Language agnosticism through ActiveX Scripting engines. ASP itself is not a language; it is a host for ActiveX Scripting (later “Windows Script”) engines. VBScript was the default, JScript was included, and third-party engines — most notably ActiveState’s PerlScript and Python implementations — could be installed and selected with a directive such as <%@ Language="PerlScript" %>.
• Composition through COM. Anything ASP could not do in script, it did by instantiating a COM object with Server.CreateObject. Database access, file I/O, mail, image manipulation, and payment processing were all delegated to compiled components, most often written in Visual Basic 6 or C++.
• Approachability over rigor. VBScript’s single Variant type, absence of a compilation step, and forgiving semantics deliberately lowered the barrier for Visual Basic developers and web designers. The cost — no type checking, no compile-time errors, and runtime failures surfacing as mid-page error messages — was accepted as part of the trade.

Key Features

The Built-in Object Model

ASP’s six intrinsic objects were its most durable contribution. Every page had access to them without any declaration:

Request, Response, Session, Application, and Server all reappear, in recognizable form, in ASP.NET — and their conceptual descendants are visible in nearly every server-side web framework written since.

Syntax

The delimiters were minimal and are immediately familiar to anyone who has written PHP or JSP:

<%@ Language="VBScript" %>
<% Option Explicit %>
<html>
<body>
  <h1>Welcome</h1>
  <%
    Dim name, i
    name = Request.QueryString("name")
    If name = "" Then name = "stranger"
  %>
  <p>Hello, <%= Server.HTMLEncode(name) %>!</p>

  <ul>
  <% For i = 1 To 5 %>
    <li>Item <%= i %></li>
  <% Next %>
  </ul>
</body>
</html>

<% ... %> encloses statements; <%= expr %> is shorthand for Response.Write expr. Code and markup interleave freely, including across control-flow boundaries, as in the loop above.

Global.asa

An application-wide file named global.asa in the site root held four event handlers — Application_OnStart, Application_OnEnd, Session_OnStart, Session_OnEnd — along with <object> declarations for application-scoped components and type library references. It served the role that a startup class or application configuration file plays in modern frameworks.

Database Access with ADO

Nearly every real ASP application talked to a database through ActiveX Data Objects (ADO), instantiated as a COM component:

<%
Dim conn, rs
Set conn = Server.CreateObject("ADODB.Connection")
conn.Open "Provider=SQLOLEDB;Data Source=dbserver;Initial Catalog=Sales;Integrated Security=SSPI"

Set rs = conn.Execute("SELECT ProductName, Price FROM Products")
Do While Not rs.EOF
  Response.Write "<li>" & Server.HTMLEncode(rs("ProductName")) & "</li>"
  rs.MoveNext
Loop

rs.Close : conn.Close
Set rs = Nothing : Set conn = Nothing
%>

The ADODB.Connection / ADODB.Recordset / ADODB.Command trio is the direct ancestor of ADO.NET’s connection and command objects.

Server-Side Includes

ASP inherited the #include directive from Server Side Includes, and it was the only code-reuse mechanism available at the file level:

<!--#include virtual="/includes/header.asp" -->
<!--#include file="functions.asp" -->

Includes are resolved before execution, so an included file’s functions and subroutines become available to the including page. In practice, large ASP applications were structured as a handful of shared include files pulled into every page.

Known Weaknesses

ASP’s shortcomings are well documented and largely explain why ASP.NET replaced it so decisively:

• No separation of concerns. Markup, business logic, and data access shared one file. Large applications became difficult to navigate and nearly impossible to unit test.
• Interpreted, not compiled. Scripts were parsed and interpreted per request (with caching of the compiled script in memory), and there was no compile-time error detection. A typo in a rarely taken branch failed in production.
• COM dependency. Extending ASP beyond scripting required writing and registering COM components, dragging in DLL registration, versioning conflicts, and apartment-threading rules that were a frequent source of subtle bugs.
• Session state coupling. In-process Session state prevented straightforward load balancing across servers without sticky sessions.
• Security footguns. String-concatenated SQL was the default idiom in most tutorials and sample code, making SQL injection endemic in ASP applications; output encoding via Server.HTMLEncode was optional and frequently skipped, producing cross-site scripting vulnerabilities.

Current Relevance

Classic ASP is dormant but not dead. Microsoft has not added features since ASP 3.0 in 2000, but ASP remains available as an optional IIS role service, and Microsoft’s position is that ASP support is tied to the support lifecycle of the host operating system and IIS version rather than having an independent end-of-life date. Practically, that means ASP applications continue to run on currently supported Windows Server releases.

The more consequential change is upstream of ASP itself: Microsoft deprecated VBScript in October 2023, stating that it will be offered as a Windows Feature on Demand before eventual removal from the operating system. Since VBScript is the default and by far the most common ASP scripting language, that deprecation sets a practical horizon for Classic ASP that its own support statements do not.

There is no official Docker image for Classic ASP. Running it in a container requires a Windows container image with IIS and the ASP role service enabled, which in turn requires a Windows container host — Classic ASP depends on IIS and COM, and no cross-platform reimplementation appears to have achieved meaningful adoption.

Why It Matters

Active Server Pages did more than serve web pages on Windows — it defined what a server-side web platform looked like for a generation of developers. The intrinsic Request/Response/Session objects, the <% %> embedding model, the file-per-URL routing convention, and the notion of application- and session-scoped state all became so widespread that they now read as obvious rather than as design decisions.

ASP also marks a specific inflection point in web history: the moment dynamic content stopped being the domain of specialists writing CGI programs in C or Perl and became something a Visual Basic developer or an ambitious HTML author could do on a Friday afternoon. That democratization drove an enormous expansion in the number of dynamic sites on the web in the late 1990s, and it is the same trade — accessibility over rigor — that PHP made independently and to even greater effect.

Its architectural failures were just as instructive. The difficulty of maintaining large ASP codebases is widely cited as motivating ASP.NET’s code-behind model, compiled pages, and event-driven server controls, and the same pain informed the MVC frameworks that followed. Classic ASP is, in that sense, the negative example against which two decades of Microsoft web development were designed.