User Requests ASP.NET Resource from Server

Like all things dealing with the Web, in the beginning was the request. That is, an ASP.NET application’s lifecycle begins when a browser requests an ASP.NET resource from an ASP.NET application on the Web server. ASP.NET resources are just one type of resource that a Web server can handle. Although we have already seen that Visual Studio 2005 provides its own local-only Web server, if an ASP.NET page is going to be available to other users, it must eventually be hosted on a machine running IIS (or some other ASP.NET-capable Web server, such as Cassini). ASP.NET is actually just one of several possible ISAPI (Internet Server API, Microsoft’s lower-level programming interface that acts as a bridge between applications and Internet services provided by IIS) extensions and filters running under IIS. An ISAPI extension is a Windows DLL that can be directly invoked by a URL and that interacts and works with a request to a Web server; for ASP.NET, the extension is aspnet_isapi.dll. An ISAPI filter, on the other hand, is a Windows DLL that modifies the incoming and outgoing data stream to and from IIS; for ASP.NET, the filter is aspnet_filter.dll, and is used only to preprocess cookieless session state.

When IIS receives a request, it first examines the extension of the requested resource, and determines which if any ISAPI extension is to handle the request. Requests for static content, such as HTML files and image files, are handled directly by IIS without using an ISAPI extension. When the .NET Framework is installed on the server, it maps .aspx, .asmx, .ascx, .ashx, and several other extensions to aspnet_isapi.dll. You can view these mappings in IIS via the Configuration option under the Home Directory or Virtual Directory tab (see Figure 2.13).