Dr. Dobb's Digest September 2009
All Web servers do essentially the same thing: They get requests and ensure a proper response is returned to the caller. Producing the response is not necessarily a task that servers can accomplish internally. For Web servers, an extensible architecture is a must -- and it is also one of the points that differentiate one Web server from another. IIS -- the Microsoft's Web server -- is no exception.
When the request for a resource arrives, IIS first verifies the type of the resource. Static resources -- images, text files, HTML pages, and script-less ASP pages -- are typically resolved directly by IIS without the involvement of any external modules. IIS accesses the file on the local Web server machine and flushes its contents to the output console so that the requesting browser can get it.
Resources that require server-side elaboration are passed on to any tailor-made modules that registered to handle those resources. Requested resources are mapped to registered modules based on their extension.
The details of how a request is being processed depend on the "process model" in use within IIS, and ultimately on the internal architecture of the Web server. The internal architecture of IIS changed significantly in the past decade to stay in sync with the progress of ASP.NET.
Originally, ASP.NET was envisioned to work in a way that revolutionized the internal architecture of the IIS of the time -- IIS 4. For about a decade new versions of ASP.NET and IIS followed one another, each reducing the gap between the design of each run time environment. In the beginning, ASP.NET was just an embedded shell within IIS 5. With the release of Windows Server 2008 and IIS 7, the circle closes and, at least when IIS 7 is configured to work in Integrated Pipeline mode, a single runtime environment exists for all incoming requests and all incoming requests go through a pipeline that is nearly identical to the classic ASP.NET runtime pipeline.
In an integrated pipeline, an ASP.NET request is like any other requests except that, at some point, it yields to a sort of simplified ASP.NET runtime environment that now just prepares the HTTP context, maps the HTTP handler, and generates the response.
When the application pool that contains an ASP.NET application running in Integrated Pipeline mode is initialized, it hosts ASP.NET runtime classes in the worker process and gives them a chance to register a set of built-in HTTP modules and handlers for the IIS pipeline events. This guarantees, for example, that Forms authentication, session state, and output caching work as expected in ASP.NET. At the same time, the ASP.NET runtime also subscribes to receive notification of when an ASP.NET request needs processing.
In IIS 7 running in Integrated Pipeline mode every request goes through a sequence of events for which both managed and unmanaged handlers can be defined. ASP.NET itself registers its own handlers for system events to capture and handle its own specific requests. Handlers of pipeline events are HTTP modules.
The big difference with classic ASP.NET and earlier versions of IIS is that any managed HTTP modules registered to handle early stages of the request can execute without first routing the request to the managed runtime of ASP.NET. A managed HTTP module can be added through the IIS manager and can operate on both managed and native requests. Similarly, a managed HTTP handler can be mapped to any resource types directly from the IIS manager or via the web.config file of the ASP.NET application. IIS doesn't serve ASP.NET requests itself though. In between the PreRequestHandlerExecute and PostRequestHandlerExecute events, IIS 7 hands an ASP.NET request on to the ASP.NET ISAPI component for actual processing.
IIS 7 supports two working modes: Classic and Integrated Pipeline. You select the working mode the application pool your application belongs to. All applications in the same pool share the same working mode. The Integrated Pipeline mode is the default mode and it makes it faster for a request to be served and gives more programming power to ASP.NET developers as it let them to control more carefully more types of resources.