Modules & the Integrated Pipeline: Handlers, Managed Modules & Native Modules

Web Servers Fundamentals never covered this at all — the module pipeline is a genuinely new topic for this course, not a deepening of something already introduced. It's also the mechanism that makes Chapter 3's own configuration sections actually do something: a locked system.webServer/authentication section only matters because an authentication module reads it on every single request, at a specific, predictable point in a fixed processing pipeline.

Request Processing: A Sequence of Named Events

Every request IIS handles moves through a fixed sequence of named pipeline events, in this order:

A module doesn't run "somewhere during the request" — it registers itself against one or more of these specific named events, and IIS calls it at exactly that point for every applicable request. An authentication module hooks AuthenticateRequest. An authorization module hooks AuthorizeRequest, immediately after. Output caching hooks ResolveRequestCache (checking for a cached response) and UpdateRequestCache (storing a new one) — the exact mechanism behind the Output Caching that Web Servers Fundamentals Chapter 9 only named in passing. The actual content-generating work — running an ASP.NET page, serving a static file — happens at ExecuteRequestHandler, which is where handlers (below) come in, distinct from modules.

Modules vs. Handlers: A Genuine Distinction

It's easy to conflate the two, but they do different jobs. A module can run on every request, hooks one or more pipeline events, and typically doesn't generate the actual response body — authentication, authorization, logging, URL rewriting, and compression are all modules. A handler is what actually produces the response content for a specific request, and exactly one handler runs per request, selected by matching the request against a table of path/verb patterns:

A request for /images/logo.png matches the StaticFile handler mapping and gets served directly off disk. A request into an ASP.NET Core app matches the AspNetCore handler mapping and gets handed off to that runtime entirely. Handler mappings are themselves just another system.webServer section — subject to exactly the same inheritance, <clear />/<add>/<remove>, and overrideModeDefault locking behavior Chapter 3 already covered.

Native Modules vs. Managed Modules

A module is either native (a compiled C++ DLL, running as part of the IIS worker process itself — HttpModule entries registered in <globalModules>) or managed (a .NET class implementing IHttpModule, running inside the .NET runtime hosted by that same worker process). Both kinds can hook the same pipeline events shown above — the distinction is about what actually executes the module's code, not which events are available to it.

Why Integrated Mode Was a Real Architectural Change

Before IIS 7, a request destined for ASP.NET ran through two genuinely separate pipelines: the native IIS pipeline handled the request first, then handed off to a completely separate ASP.NET pipeline (via the ISAPI extension aspnet_isapi.dll) for anything .aspx. A managed IHttpModule could only ever see the second, ASP.NET-only pipeline — it had no visibility into, say, a plain static file request, since that never entered the ASP.NET pipeline at all. Integrated mode, introduced in IIS 7 and the modern default ever since, merges these into one single pipeline: the same eleven events shown above apply uniformly, and a managed module can now hook AuthenticateRequest for any request — a static image, a classic ASP page, anything — not just ASP.NET content. Classic mode (the old two-pipeline behavior) still exists for legacy application compatibility, but is genuinely a compatibility fallback at this point, not a real architectural choice for anything new.

Hands-On Exercises