从Denali到1996年发布
动态服务器网页，即Active Server Pages，简称ASP，是微软为网站服务器提供的脚本运行环境。它让页面把超文本标记语言HTML、脚本和服务器组件组合起来，在收到访问请求时生成内容。企业内部网与公开网站都可使用这种方式，将浏览页面与后台业务处理连接起来。
1996年11月4日，微软在开发者大会公告中明确说，ASP此前名为Denali，并计划随Internet Information Server 3.0推出。12月10日的发布公告则宣布，IIS 3.0将在当周提供，Windows NT Server 4.0用户可以下载。因此，1996年对应的是技术公布、测试与首批正式交付相接的阶段；公告日期不宜直接当成所有用户实际取得软件的日期。
IIS团队与组件协作
ASP并非只有一个独立语言设计者的故事。微软的IIS团队把脚本执行纳入服务器产品，外围开发者又通过组件和范例扩展使用方法。乔治·V.赖利保存的源代码说明提供了一个具体参与者的记录：1996年10月至1997年5月，他在华盛顿州雷德蒙德的MicroCrafts咨询公司任职，为微软IIS团队编写ASP示例组件。
这些组件大多利用Active Template Library，即ATL这一C++组件开发库。赖利后来进入IIS开发团队，从事ASP性能改进。他保存的范例包括广告轮换、浏览器能力检测、页面计数以及多种语言的简单组件。这个经历说明，运行引擎、组件接口、示范代码和性能工作是相互联系的环节；并不能据此把赖利称作ASP唯一发明人。
参考：[3]
页面如何在服务器加工
早期ASP文件可以保留普通HTML，再在特定分隔符中嵌入脚本。默认脚本语言是VBScript，也可选择JScript等受支持的语言。1997年的技术书将ASP.DLL放在IIS服务器进程中解释：请求交给服务器处理后，页面中的服务器脚本先执行，其产生的文字与静态部分组成返回内容。
例如，一个以VBScript运行的自拟片段“Total: <% Response.Write 3 * 7 %>”，会把乘法结果写入响应，返回“Total: 21”。这里的Response.Write负责输出，乘法由服务器端脚本求值；浏览器接收的是结果，而不是等待它自己解释这条VBScript语句。这个例子只演示生成响应，并不需要用户输入或数据库。
因而，ASP页面应通过配置正确的服务器访问。直接在浏览器打开磁盘上的文件，并不等于执行服务器脚本。若页面另外输出浏览器端脚本，那部分仍要由客户端处理，两种执行地点应明确区分。
一次请求与连续访问
ASP把常见网页操作整理成内建对象。Request提供客户端送来的数据，例如表单字段、查询参数与Cookie；Response则负责返回内容，也能调整响应头或发出重定向。程序不必每次都从最底层自行整理整个请求与响应。
一次访问结束后，应用往往还要记住用户先前作出的选择。Session对象可在同一会话跨页面保留数据，会话过期或被终止时再释放；Application对象则保存应用范围的信息。二者范围不同，不能把某位用户的选择随意放进所有访问者共享的状态。
从这一模型可以看出，对象把输入、输出和状态分开，却不替程序决定业务规则。会话超时后的处理、共享数据的范围与页面跳转，仍需开发者自行设计。
参考：[5]
数据库与可视化开发
ASP的目标还包括把已有业务能力接到网页。1996年10月28日，微软在圣何塞Site Builder大会展示代号Internet Studio的开发工具。开发工具主管鲍勃·穆利亚将它定位为连接服务器处理与企业数据库的可视化环境。演示时仍是预发布阶段，不能把工具亮相等同商业版本上市。
同期公告列出数据库查询、设计工具，以及利用数据对象访问ODBC数据库的方式；服务器上的COM组件也可向页面提供计算结果。工具与FrontPage 97使用相通的项目模型，让编程人员和网页作者协作。这样，页面编排、查询数据与调用业务组件可以组成工作流程，而不只是手工改动静态文件。
参考：[6]
影响与后续技术路线
多伊尔与洛佩斯的技术综述把ASP放在脚本式模板的发展脉络中：大量网页只有少量内容需要变化，将逻辑嵌入固定页面，能降低生成动态内容的门槛。ASP又借助COM连接既有组件，使微软服务器环境中的业务程序更容易通过网页提供服务。
同一研究也指出局限：页面中混合显示与逻辑，不会自动解决大型应用的组织问题；平台依赖、运行解释成本及可靠性仍需开发者处理。后来ASP.NET利用.NET框架重新组织网页应用，不能简单视为给原脚本环境换名。两者虽保留若干相似对象名，技术参考明确区分了旧ASP对象与.NET中的类。