Recent from talks
Nothing was collected or created yet.
Active Server Pages
View on WikipediaThis article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
| Active Server Pages (ASP) | |
|---|---|
| Developer | Microsoft |
| Stable release | 3.0
/ February 17, 2000 |
| Type | Web application framework |
| License | Proprietary software |
| Website | www |
| Active Server Pages | |
|---|---|
| Filename extension |
.asp |
| Developed by | Microsoft |
Active Server Pages (ASP) is Microsoft's first server-side scripting language and engine for dynamic web pages.
It was first released in December 1996, before being superseded in January 2002 by ASP.NET.
History
[edit]Initially released as an add-on to Internet Information Services (IIS) via the Windows NT 4.0 Option Pack (1996), it is included as a component of Windows Server (since the initial release of Windows 2000 Server). There have been three versions of ASP, each introduced with different versions of IIS:
- ASP 1.0 was released in December 1996 as part of IIS 3.0
- ASP 2.0 was released in September 1997 as part of IIS 4.0
- ASP 3.0 was released in November 2000 as part of IIS 5.0
ASP 2.0 provides six built-in objects: Application, ASPError, Request, Response, Server, and Session. A Session object, for example, represents a session that maintains the state of variables from page to page.[1] The Active Scripting engine's support of the Component Object Model enables ASP websites to access functionality in compiled libraries such as dynamic-link libraries.
ASP 3.0 does not differ greatly from ASP 2.0 but it does offer some additional enhancements such as Server.Transfer method, Server.Execute method, and an enhanced ASPError object. ASP 3.0 also enables buffering by default and optimized the engine for better performance.
ASP was supported until 14 January 2020 on Windows 7.[2] The use of ASP pages will be supported on Windows 8 for a minimum of 10 years from the Windows 8 release date.[2] ASP is supported in all available versions of IIS as of 2025.[3]
Architecture
[edit]ASP uses scripting on the server to generate content that is sent to the client's web browser via HTTP response. The ASP interpreter reads and executes all script code between <% and %> tags, the result of which is content generation. These scripts were written using VBScript, JScript, or PerlScript. The @Language directive, the <script language="language" runat="server" /> syntax or server configuration can be used to select the language. In the example below, Response.Write Now() is in an HTML page; it would be dynamically replaced by the current time of the server.
| Server side | Client Side |
|---|---|
The server's current time:
<%
Response.Write Now()
%>
|
The server's current time:
8/11/2015 6:24:45 PM
|
Web pages with the .asp filename extension use ASP, although some web sites disguise their choice of scripting language for security purposes by using the more common .htm or .html extensions. Pages with the .aspx extension use compiled ASP.NET; however, ASP.NET pages may still include some ASP scripting. The introduction of ASP.NET led to use of the term Classic ASP for the original technology.
Sun Java System ASP (formerly ChiliSoft ASP) was a popular and reportedly complete emulator,[4] but it has been discontinued.
The Session object
[edit]Stores variables accessible only to a single visitor, which are local variables.
<%
If Len(Request.QueryString("name")) > 0 Then
Session("name") = Request.QueryString("name")
End If
Response.Write "Welcome " & Server.HTMLEncode(Session("name")) & "!"
%>
The session object is file based and multiple concurrent read and/or write requests will be blocked and processed in turn.
See also
[edit]References
[edit]- ^ The session data is kept server-side, the ID is saved as a HTTP Cookie. Source: ASP and Web Session Management, Microsoft
- ^ a b "Active Server Pages (ASP) support in Windows". Support (4.0 ed.). Microsoft. 30 January 2012. Retrieved 11 August 2015.
- ^ Source: [1], Microsoft
- ^ Weissinger, Keyton (6 October 2009). ASP in a Nutshell: A Desktop Quick Reference. O'Reilly Media, Inc. ISBN 978-1-4493-7959-9. Retrieved 9 October 2013.
External links
[edit]Active Server Pages
View on Grokipedia<% and %>.[1] When a client requests an ASP page, the server executes the embedded scripts—primarily in VBScript (Microsoft's Visual Basic variant, used in most examples for its simplicity) or JScript (Microsoft's implementation of ECMAScript)—to perform tasks like database queries, form processing, or content personalization.[1] Developers can extend functionality using COM (Component Object Model) components, compiled as DLLs in languages like Visual C++ or Visual Basic, to handle complex operations such as connecting to databases or implementing business logic.[1] Key built-in objects like Request, Response, Session, and Application provide access to HTTP data, output generation, user session management, and application-wide state, respectively, enabling robust server-side logic.[4]
ASP's architecture integrates tightly with IIS, processing scripts on the server to reduce client-side workload and enhance security by keeping code hidden from end-users.[5] Although it revolutionized web development in the late 1990s by facilitating rapid prototyping and database-driven sites, ASP was largely superseded by ASP.NET starting with version 1.0 in January 2002, which introduced a compiled, object-oriented framework based on the .NET runtime for greater scalability and performance.[6] Despite this, Classic ASP remains supported in all current versions of IIS on supported Windows operating systems, tied to the host OS lifecycle, allowing legacy applications to run without active development or new features from Microsoft.[5]
Overview
Definition and Purpose
Active Server Pages (ASP) is Microsoft's server-side scripting technology that enables developers to embed scripts within HTML files to generate dynamic web pages, with the processing occurring on the web server before the content is delivered to the client's browser.[1] Introduced in 1996 as part of Internet Information Services (IIS), ASP allows for the creation of interactive web applications by combining static HTML with executable server-side code.[7] The primary purpose of ASP is to facilitate dynamic content generation, user form handling, and database interactions, addressing the limitations of early static web technologies.[1] For instance, it supports tasks such as personalizing page content based on user sessions or retrieving and displaying data from databases like Microsoft Access or SQL Server, which were common in early web applications.[1] In contrast to static HTML, which delivers unchanging files directly from the server to the browser, ASP operates through a dynamic request-response cycle: a client submits a request for an .asp file, the server processes embedded scripts to generate customized HTML output, and then returns the result to the client.[1] This model enables real-time adaptability, such as inserting the current date or responding to form inputs, without requiring client-side execution. ASP achieves this through built-in intrinsic objects that manage aspects like sessions and requests, though their detailed roles are explored elsewhere.[1]Key Features and Capabilities
Active Server Pages (ASP) supported multiple scripting languages, enabling developers to embed dynamic code directly within HTML documents. The primary language was VBScript, with built-in support for JScript and the option to integrate third-party engines like PerlScript through COM scripting hosts.)[8] This flexibility allowed developers to choose languages familiar to their workflow, though VBScript's similarity to Visual Basic made it the default for most applications.[9] A core capability of ASP was its server-side execution model, where scripts ran entirely on the web server, generating static HTML output sent to the client browser. This separation of client and server processing ensured that sensitive logic remained hidden from end-users, while allowing dynamic content generation based on user inputs, such as form data or query parameters.[9] The model facilitated stateless interactions by default, with optional session management via intrinsic objects like Session and Application to maintain state across requests.[9] ASP provided robust capabilities for data handling, including database connectivity through ActiveX Data Objects (ADO), a COM-based library for querying and manipulating relational databases like SQL Server or Access. Developers could establish connections, execute SQL statements, and retrieve recordsets directly in scripts, enabling data-driven web pages without external middleware.[10] File input/output operations were supported via the FileSystemObject from the Scripting Runtime library, allowing scripts to read, write, and manage files on the server filesystem.[11] Email sending was achievable using Collaboration Data Objects (CDO) for Windows NT, a COM component that configured SMTP messages with attachments and recipients from within ASP pages.[12] Integration with COM components extended ASP's functionality, permitting reuse of pre-built binaries (e.g., DLLs created in Visual Basic or C++) for complex tasks like business logic or custom controls, which could be instantiated via the Server.CreateObject method.[8] This feature offered advantages in rapid prototyping for small-scale web applications, as it allowed quick assembly of dynamic sites by embedding scripts in HTML without the overhead of full CGI setups or compiled executables.[9] However, ASP's reliance on interpreted scripting languages introduced performance overhead, as code executed line-by-line at runtime without pre-compilation, leading to slower response times compared to native or compiled alternatives under high load.[13] This limitation made ASP suitable for prototyping but less ideal for large-scale, high-traffic deployments without optimization techniques like buffering or component offloading.[14]History
Origins and Development
Active Server Pages (ASP) was developed by Microsoft in the mid-1990s as an extension to its Internet Information Services (IIS) web server software, aiming to enable the creation of dynamic web content on Windows-based servers.[15] Originally code-named "Denali", ASP was formally announced by Microsoft in November 1996 before its release in December.[16] The technology emerged to compete with existing server-side approaches like the Common Gateway Interface (CGI), which relied on external scripts often written in Perl, and the more low-level Internet Server Application Programming Interface (ISAPI).[15] By integrating scripting directly into the server environment, ASP sought to overcome the performance overhead and complexity of CGI, which required spawning separate processes for each request, while providing a more accessible alternative to ISAPI's C/C++ programming requirements.[15] The primary motivations for ASP's creation stemmed from the growing demand for dynamic websites beyond static HTML pages, particularly in enterprise environments where Windows developers needed simpler tools for personalization and database-driven content.[15] Microsoft designed ASP to appeal to programmers familiar with [Visual Basic](/page/Visual Basic), offering an interpreted, text-based scripting model that integrated seamlessly with HTML and reduced the need for compiled code or external tools.[15] This approach addressed the limitations of static pages by allowing server-side logic to generate customized responses, such as user-specific data or real-time updates, without the inefficiencies of CGI scripts.[14] Key initial design decisions emphasized ease of use and extensibility within the Windows ecosystem. These choices positioned ASP as an integrated, Windows-native solution for early web application development. ASP was first released as part of IIS 3.0 in December 1996.[17]Release Timeline and Adoption
Active Server Pages (ASP) was first released in December 1996 as part of Internet Information Server (IIS) 3.0, bundled with Windows NT 4.0, enabling server-side scripting for dynamic web content generation.[17] The technology saw its next major update with ASP 2.0 in September 1997, integrated into IIS 4.0 as part of the Windows NT 4.0 Option Pack, which introduced incremental performance enhancements and additional scripting capabilities to handle growing web demands.[18] ASP 3.0 followed in November 2000 with IIS 5.0 on Windows 2000 Server, adding improved error handling via the new ASPError object and built-in support for XML processing, further bolstering reliability for complex applications.[19][20] Adoption of ASP surged during the late 1990s and early 2000s, particularly within enterprise environments leveraging the Microsoft ecosystem, as it provided seamless integration with tools like Visual Basic and SQL Server for building database-driven sites. By 2001, Microsoft IIS servers—predominantly powering ASP applications—captured approximately 26% of the active web server market, reflecting ASP's significant role in server-side development at its peak.[21] ASP's prominence waned in the mid-2000s due to the emergence of open-source alternatives like PHP and Java Servlets, which offered cross-platform flexibility and lower costs, alongside Microsoft's own shift to the more robust ASP.NET framework released in 2002. Mainstream support for ASP 3.0 effectively concluded around 2002 with the focus on ASP.NET, though security updates continued through extended support phases for underlying Windows Server versions, such as until July 2015 for Windows Server 2003.[20]Technical Architecture
Server-Side Processing Model
Active Server Pages (ASP) operates through a server-side execution pipeline integrated with Internet Information Services (IIS). When IIS receives an HTTP request for a file with the .asp extension, it routes the request to the ASP engine via script mappings. The engine parses the .asp file, which consists of static HTML intermixed with script blocks delimited by <% and %> tags. It separates the static content from the dynamic script portions, executes the scripts on the server to generate additional HTML or other output, and then merges everything into a complete response document before sending it back to the client browser.)[22] The core of this processing is handled by ASP.dll, an Internet Server Application Programming Interface (ISAPI) extension loaded into the IIS process space. ASP.dll acts as the interpreter for the embedded scripts, typically written in VBScript or JScript, executing them at runtime to perform tasks such as data retrieval or logic processing. Unlike static HTML files served directly by IIS, .asp requests trigger this dynamic interpretation, enabling the generation of personalized content without requiring separate executable programs.[22]) By default, the ASP processing model is stateless, meaning each request is handled independently without inherent memory of prior interactions, aligning with the stateless nature of the HTTP protocol. Developers can maintain state across requests using intrinsic objects, such as Session for user-specific data or Application for shared variables, which are initialized and managed during the pipeline execution.) This model differs fundamentally from client-side scripting, like JavaScript executed in the browser, as all computation occurs on the server, ensuring sensitive operations remain hidden from the client while producing standard HTML output. Compared to Common Gateway Interface (CGI) scripts, ASP avoids the overhead of spawning a new operating system process for each request; instead, it leverages lightweight threads within the persistent IIS process via ISAPI, reducing startup time and resource consumption.)[22][23] Performance in ASP stems from its interpreted execution of scripts, where code is processed at runtime rather than compiled beforehand, which introduces overhead compared to fully compiled alternatives. While this allows rapid development and flexibility, it can limit scalability for high-traffic sites due to repeated interpretation per request; however, integrating compiled COM components mitigates this by offloading intensive tasks to pre-compiled binaries, and the in-process ISAPI model provides better efficiency than CGI's process-per-request approach.[24][22][23]Supported Scripting Languages
Active Server Pages (ASP) primarily supports two scripting languages provided by Microsoft: VBScript and JScript. VBScript, the default language, features a syntax similar to Visual Basic, making it accessible for developers familiar with Windows-based programming environments. This design choice facilitated easier adoption among Microsoft-centric developers during ASP's early years.[25][1] JScript serves as the alternative, implementing ECMAScript standards (primarily version 3) and offering syntax akin to client-side JavaScript, which appealed to web developers seeking consistency between server- and client-side code. The language for an ASP page is declared using the@LANGUAGE directive at the top of the file, such as <%@ Language="VBScript" %> or <%@ Language="JScript" %>, allowing developers to specify or override the default on a per-page basis.[25][26][27]
VBScript's strengths include its straightforward syntax and built-in support for common tasks like string manipulation and error handling via On Error Resume Next, which suited beginners and rapid prototyping but lacked advanced features such as full object-oriented programming or modern data structures. In contrast, JScript provides better exception handling with try-catch-finally blocks and closer alignment with cross-platform JavaScript practices, though its Microsoft-specific implementation limited broader standardization and interoperability. These trade-offs influenced developer choice: VBScript for simplicity in Windows ecosystems, JScript for JavaScript-like portability.[1][25]
Beyond the native options, ASP supports third-party scripting languages through additional ActiveX scripting engines installed as DLLs, such as PerlScript for Perl code or Python implementations, though these require separate downloads and configuration, lacking native integration and broad adoption. Scripts in any supported language can interact with language-agnostic COM components for extended functionality.[8][25][28]
Following the release of ASP 3.0 in 2000, no significant updates were made to the core scripting languages, leaving VBScript and JScript with features frozen at late-1990s levels, such as limited support for regular expressions in VBScript and no native modules or async capabilities. This stagnation has rendered them outdated relative to modern server-side languages like JavaScript (Node.js) or Python (Django), exacerbated by Microsoft's phased deprecation of VBScript starting in 2023, with full removal planned from future Windows versions.[29][30][31]
Intrinsic Objects and Their Roles
Active Server Pages (ASP) provides a set of intrinsic objects that are automatically available to scripts without explicit instantiation, enabling developers to interact with the web server, manage state, and handle HTTP communications. These objects, implemented as COM components, facilitate common tasks such as data retrieval, output generation, error handling, and resource management within the server-side scripting environment.[4] The Server object serves as a utility for server-level operations, offering methods to manipulate paths, decode strings, and instantiate components. ItsMapPath method converts virtual paths to physical file system paths, which is essential for accessing server resources like files or directories; for example, Server.MapPath("/myapp/data.txt") resolves to the actual disk location. The URLDecode method reverses URL encoding on strings, converting sequences like %20 back to spaces for proper handling of user input. Additionally, CreateObject allows the creation of COM objects on the server, such as database connections via Server.CreateObject("ADODB.Connection"), enabling integration with external components. This object operates at a global scope, independent of individual requests or sessions.[32]
The Application object manages state shared across all users and sessions in the web application, functioning as a global namespace for variables and objects that persist for the application's lifetime. Developers store application-wide data using it, such as counters or configuration settings, via assignments like Application("TotalUsers") = 100. To ensure thread safety in multi-user environments, the Lock and Unlock methods provide exclusive access during updates, preventing concurrent modifications; for instance, code might use Application.Lock, update a value, then Application.Unlock. This global scope contrasts with user-specific storage, making it suitable for non-personalized data.)
In contrast, the Session object maintains state for individual users across multiple requests within a defined session period, typically tracked via cookies. It stores per-user variables, such as login details, with assignments like Session("UserName") = "[John Doe](/page/John_Doe)", which remain accessible until the session ends. The Abandon method explicitly terminates the session and releases its resources, while the Timeout property sets the idle duration in minutes before automatic expiration (defaulting to 20 minutes, configurable in IIS). This per-user scope supports personalized experiences without affecting other visitors.[33]
The Request and Response objects handle input and output for each HTTP transaction, operating at a per-request scope to encapsulate the exchange between client and server. The Request object accesses incoming data through collections like Form for POST-submitted values (e.g., Request.Form("username") retrieves a form field) and QueryString for GET parameters (e.g., Request.QueryString("id") for URL arguments). Complementarily, the Response object generates output, with Write sending content to the client as in Response.Write("Hello, World!"), and methods like Redirect for navigation or AddHeader for custom HTTP headers. These objects enable dynamic content generation based on user input.[34][35]
For error management, the Err object (also known as ASPError) captures runtime exceptions, providing details to aid debugging. Key properties include Number for the error code, Description for a textual explanation, and Source for the originating component; usage might involve If Err.Number <> 0 Then Response.Write(Err.Description). The Clear method resets the object after handling, ensuring clean state for subsequent operations. This object becomes populated automatically upon errors, supporting robust script error recovery.[36]
These intrinsic objects differ in scope to align with ASP's stateless HTTP nature: Application for global, shared persistence; Session for user-specific continuity; and Request/Response for transient, single-interaction handling, with Server and Err available as needed across contexts.[4]
Development Practices
Writing and Structuring ASP Pages
Active Server Pages (ASP) files are text files with a.asp extension that integrate HTML markup with server-side scripting code, enabling dynamic web content generation. These files are typically created using any plain text editor, such as Notepad, and must be placed in a virtual directory configured for script execution on an IIS server. The core structure involves embedding script commands within HTML, where server-side code executes on the web server before the resulting HTML is sent to the client's browser.[37][9]
Server-side scripts in ASP are delimited by <% and %> tags for inline execution, allowing seamless mixing of static HTML and dynamic code. For multi-line scripts, developers can use <script runat="server"> blocks, which support the specified scripting language. Expressions for outputting values, such as variables or function results, use the shorter <%= form, like <%= Now() %> to display the current date and time. This delimiter system ensures that only the enclosed code is processed server-side, while surrounding HTML remains unchanged.[37][9]
ASP supports processing directives to control file interpretation, placed at the beginning of the file. The @LANGUAGE directive specifies the scripting language, defaulting to VBScript but configurable to JScript, as in <%@ Language="VBScript" %>, which influences how code blocks are parsed. The #include directive promotes code reuse by inserting content from external files, using syntax like <!-- #include file="header.inc" --> for virtual paths or <!-- #include virtual="/includes/footer.asp" --> for relative includes, reducing duplication across pages. These directives must appear before any script code to take effect.[38][37]
Common scripting patterns in ASP leverage intrinsic objects and control structures for interactivity. Form processing typically uses the Request.Form collection to access submitted data, such as username = Request.Form("username"), enabling validation or storage of user input from HTML forms. Conditional logic employs If...Then...Else statements in VBScript, for example:
<%
Dim timeOfDay
timeOfDay = Hour(Now())
If timeOfDay < 12 Then
Response.Write "Good Morning!"
Else
Response.Write "Good Afternoon!"
End If
%>
<%
Dim timeOfDay
timeOfDay = Hour(Now())
If timeOfDay < 12 Then
Response.Write "Good Morning!"
Else
Response.Write "Good Afternoon!"
End If
%>
For Each for iterating collections or For...Next for counters, facilitate repetitive tasks, such as generating a list:
<%
Dim i, items(2)
items(0) = "Apple"
items(1) = "Banana"
items(2) = "Cherry"
For Each item In items
Response.Write item & "<br>"
Next
%>
<%
Dim i, items(2)
items(0) = "Apple"
items(1) = "Banana"
items(2) = "Cherry"
For Each item In items
Response.Write item & "<br>"
Next
%>
On Error Resume Next statement, which allows execution to continue after a runtime error by skipping to the next line. Following potential error points, developers check the Err object's properties—such as Err.Number for the error code and Err.Description for details—to respond appropriately, then clear the error with Err.Clear. For instance:
<%
On Error Resume Next
' Code that might fail, e.g., accessing a non-existent object
If Err.Number <> 0 Then
Response.Write "Error: " & Err.Description
Err.Clear
End If
%>
<%
On Error Resume Next
' Code that might fail, e.g., accessing a non-existent object
If Err.Number <> 0 Then
Response.Write "Error: " & Err.Description
Err.Clear
End If
%>
Err object is intrinsic and global, automatically populated on errors without needing instantiation.[39][40]
Best practices for ASP development emphasize maintainability through separation of logic from presentation, achieved by isolating script commands in includes or reusable components rather than embedding them deeply within HTML. Developers should minimize global variables, such as Application or Session scope items, to avoid unintended state sharing across users or sessions, opting instead for local variables within procedures to enhance predictability and debugging. Using #include files for common functions further supports modularity, while consistent indentation and comments in script blocks improve readability.[37][38]
Integration with Components and Databases
Active Server Pages (ASP) integrates with external components primarily through the Component Object Model (COM), allowing developers to instantiate reusable server-side objects for tasks such as business logic processing. TheServer.CreateObject method is used to create instances of COM components, specifying the object's ProgID or CLSID, which results in an object with page-level scope by default.[41] For example, a developer might create a custom COM component in Visual Basic for data validation and invoke it in an ASP page as follows:
<%
Dim objComponent
Set objComponent = Server.CreateObject("MyApp.CustomValidator")
objComponent.ValidateInput(Request.Form("userInput"))
Set objComponent = Nothing
%>
<%
Dim objComponent
Set objComponent = Server.CreateObject("MyApp.CustomValidator")
objComponent.ValidateInput(Request.Form("userInput"))
Set objComponent = Nothing
%>
<OBJECT> tag with the RUNAT=Server attribute, providing an alternative to programmatic instantiation.[42]
Database connectivity in ASP relies on ActiveX Data Objects (ADO), a Microsoft library that facilitates access to OLE DB-compliant data sources, including relational databases like SQL Server and Microsoft Access. Developers typically create an ADO Connection object to establish a link using a provider-specific connection string, such as for SQL Server: "Provider=SQLOLEDB;Data Source=servername;Initial Catalog=databasename;Integrated Security=SSPI;".[43] Once connected, SQL queries are executed via a Command object or directly on a Recordset object, which holds the results for manipulation and display. A common pattern involves opening a Recordset with a SELECT query and iterating through records in a loop to generate HTML output, as in this example:
<%
Dim conn, rs
Set conn = Server.CreateObject("ADODB.Connection")
conn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\path\to\database.mdb;"
Set rs = Server.CreateObject("ADODB.Recordset")
rs.Open "SELECT * FROM Users", conn
Do While Not rs.EOF
Response.Write "<p>" & rs("Name") & "</p>"
rs.MoveNext
Loop
rs.Close
conn.Close
Set rs = Nothing
Set conn = Nothing
%>
<%
Dim conn, rs
Set conn = Server.CreateObject("ADODB.Connection")
conn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\path\to\database.mdb;"
Set rs = Server.CreateObject("ADODB.Recordset")
rs.Open "SELECT * FROM Users", conn
Do While Not rs.EOF
Response.Write "<p>" & rs("Name") & "</p>"
rs.MoveNext
Loop
rs.Close
conn.Close
Set rs = Nothing
Set conn = Nothing
%>
#include directive, such as <!--#include file="dbutils.inc"--> to modularize connection logic.[44]
Application-wide and session-specific behaviors are managed through the optional global.asa file, which defines event handlers for the intrinsic Application and Session objects. The Application_OnStart subroutine executes once when the application initializes, ideal for setting global variables or opening shared database connections, while Application_OnEnd runs upon application shutdown to clean up resources.[44] Similarly, Session_OnStart triggers at the beginning of a user's session for personalized setup, and Session_OnEnd handles cleanup when the session times out or ends. An example in global.asa might look like:
<script language="VBScript" runat="server">
Sub Application_OnStart
Application("dbConn") = Server.CreateObject("ADODB.Connection")
Application("dbConn").Open "DSN=MyDatabase;"
End Sub
Sub Application_OnEnd
Application("dbConn").Close
Set Application("dbConn") = Nothing
End Sub
Sub Session_OnStart
Session("userID") = Request.ServerVariables("LOGON_USER")
End Sub
Sub Session_OnEnd
' Log session end if needed
End Sub
</script>
<script language="VBScript" runat="server">
Sub Application_OnStart
Application("dbConn") = Server.CreateObject("ADODB.Connection")
Application("dbConn").Open "DSN=MyDatabase;"
End Sub
Sub Application_OnEnd
Application("dbConn").Close
Set Application("dbConn") = Nothing
End Sub
Sub Session_OnStart
Session("userID") = Request.ServerVariables("LOGON_USER")
End Sub
Sub Session_OnEnd
' Log session end if needed
End Sub
</script>
Deployment and Security
Configuration with IIS
Active Server Pages (ASP) configuration within Internet Information Services (IIS) involves enabling the ASP module, setting up virtual directories, and managing application pools to ensure stable deployment of ASP applications. ASP has been supported since IIS 3.0, introduced with Windows NT 4.0 Option Pack, and remains compatible through IIS 10.0 on Windows Server 2016–2025 and Windows 10/11.[5][46] To enable ASP, administrators must first install the IIS role with the ASP feature selected during setup via Server Manager on Windows Server or Turn Windows features on or off in Control Panel on client editions like Windows 10. Once installed, IIS Manager provides the primary interface for configuration: navigate to the site or server level, select the ASP feature under IIS, and enable it by ensuring the module is active in the site's handler mappings for .asp file extensions. Script permissions are configured at the directory level by right-clicking a folder or virtual directory, selecting Properties, and setting Execute permissions to allow script execution while restricting unnecessary access. Virtual directories for ASP files are created in IIS Manager by adding a new virtual directory under the site's structure, mapping it to a physical path, and configuring application boundaries to isolate ASP content.[46][47] Application pools enhance stability by isolating ASP applications; each pool runs in a separate worker process (w3wp.exe), preventing one application's failure from affecting others. In IIS Manager, create a new application pool under the Application Pools node, assign it to the ASP site or virtual directory via Basic Settings, and configure recycling options—such as time-based (e.g., every 29 hours) or memory-based thresholds—to proactively restart processes and mitigate memory leaks common in long-running ASP scripts. For optimal performance, set the pool's .NET CLR version to "No Managed Code" since classic ASP does not rely on the .NET runtime.[48][49] Debugging and monitoring are facilitated through ASP-specific settings in IIS Manager's ASP feature pane: enableappAllowDebugging for server-side debugging (though disabled by default for security) and set errorsToNTLog to true to log errors to the Windows Event Log for detailed analysis. Tracing integrates with IIS failed request tracing by enabling the feature at the server level and configuring rules to capture ASP-related errors, which can then be viewed in log files or the Event Tracing for Windows (ETW) viewer. Detailed errors are surfaced by adjusting the Error Pages feature to "Detailed errors" mode, overriding any custom error pages to display script-specific details like line numbers (aided by the default calcLineNumber setting). Session management, such as state persistence, can be briefly tuned via the <session> element in ASP configuration, often aligned with application pool settings for consistency.[46][50][51]
Despite its support, ASP holds a deprecated status in modern IIS deployments, as Microsoft recommends transitioning to ASP.NET for new development, though it continues to run reliably on Windows 10/11 and Server 2016–2025 without requiring additional compatibility modes.[5][52]
Common Security Vulnerabilities and Mitigations
Active Server Pages (ASP) applications are susceptible to several common security vulnerabilities, primarily due to their reliance on direct scripting and legacy components. One prevalent issue is SQL injection, where unescaped user inputs from objects like Request.Form or Request.QueryString are concatenated into ADO database queries, allowing attackers to alter SQL statements and potentially access or manipulate data. For instance, an input like' OR 1=1 -- can bypass authentication in a query such as SELECT * FROM Users WHERE UserName = '" & Request.Form("username") & "'. To mitigate this, developers should use parameterized queries with ADODB.Command objects, which separate data from code, or employ stored procedures to limit dynamic SQL execution. Additionally, rigorous input validation using regular expressions to allow only expected characters (e.g., alphanumeric patterns) and escaping single quotes by replacing them with double quotes ('') can further reduce risks.[53]
Cross-site scripting (XSS) and buffer overflows represent another category of threats in ASP, exacerbated by the outdated nature of VBScript and potential issues in associated ISAPI extensions or COM+ objects. XSS occurs when unvalidated user input is output directly to the browser without encoding, enabling attackers to inject malicious scripts that execute in users' sessions. Buffer overflows can arise from assuming fixed sizes for variables in COM+ components or ISAPI filters, leading to memory corruption if inputs exceed allocated space. Mitigation strategies include always encoding outputs with Server.HTMLEncode() for HTML contexts or Server.URLEncode() for URLs to neutralize script tags, and performing comprehensive input sanitization to reject or escape dangerous characters. For buffer issues, developers should validate input lengths strictly and avoid fixed-size assumptions in custom components, while leveraging COM+ for safer processing of user data.[54]
Session hijacking poses risks in ASP applications that rely on session state, particularly when session IDs are predictable or transmitted insecurely over HTTP, allowing attackers to impersonate users by stealing cookies. Weak session management in classic ASP can expose session data if not protected. Enabling Secure Sockets Layer (SSL) encrypts session cookies and prevents interception, while setting cookies with the Secure flag ensures they are only sent over HTTPS. Implementing additional checks, such as binding sessions to client IP addresses or user agents in the Session_OnStart event, can detect and invalidate hijacked sessions.[54]
Configuration-related vulnerabilities in ASP setups can leak sensitive information, aiding attackers in reconnaissance or exploitation. Displaying detailed error messages in production environments reveals internal paths, variable names, or database details, which should be disabled to show generic errors instead. Similarly, using default database accounts like "sa" with weak or no passwords increases unauthorized access risks; strong, unique passwords and removal of unnecessary default accounts are essential. In IIS configurations, restricting access to application files like global.asa prevents exposure of session and application-level object declarations. As a legacy technology, Classic ASP does not receive new feature development, but security updates are provided through the underlying Windows OS support. Known exploits in older IIS/ASP components may persist in unpatched environments, heightening exposure for unmaintained systems. Administrators should apply all available OS and IIS security updates and consider isolating ASP applications in segmented networks.[5][55]
