Challenge 1: Modules vs. Handlers -- Solution Walkthrough

A module and a handler serve fundamentally different roles in IIS's
pipeline, even though both are configured under system.webServer.

A module hooks one or more of the fixed pipeline events (BeginRequest,
AuthenticateRequest, AuthorizeRequest, ResolveRequestCache, and so on)
and can run against every single request that reaches that event,
regardless of what the request is actually for. Modules generally
don't produce the response body themselves -- they do cross-cutting
work like authentication, authorization, logging, URL rewriting, or
compression, any number of which can legitimately apply to the same
request at different points in the pipeline.

A handler is different: it's specifically responsible for actually
generating the response content, and IIS selects exactly one handler
per request by matching the request's path and HTTP verb against the
handler mappings table (e.g. StaticFile for a plain file GET,
AspNetCoreModuleV2 for an ASP.NET Core app). Only one handler can
"own" producing the content for a given request -- it wouldn't make
sense for two different handlers to both try to generate the same
response body -- which is why handler selection happens at one
specific pipeline event (MapRequestHandler) and only one wins,
while many modules can each legitimately touch the same request at
their own separate events without any such conflict.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader has internalized the core
distinction the chapter draws between "many can apply" (modules,
cross-cutting concerns) and "exactly one applies" (handlers, content
generation) -- not just that both terms exist, but why the pipeline
model requires that asymmetry.