The request lifecycle in ASP.NET MVC begins when a client transmits an HTTP packet to IIS and concludes once the generated resposne stream is flushed back to the browser. Understanding the internal routing and execution chain reveals how the framework delegates control across multiple architectural layers, enabling developers to intercept or modify processing at precise execution points.

The Underlying HTTP Pipeline

Before MVC-specific logic engages, every incoming request must traverse the standard ASP.NET runtime. The central orchestrator for this phase is HttpApplication, which manages a sequential series of pipeline events. While the framework exposes numerous stages, the critical integration points for MVC occur around authorization, cache resolution, and handler mapping.

External components intercept these stages by implementing the IHttpModule contract. During initialization, modules attach event handlers to specific pipeline phases:

public interface IHttpModule
{
    void Initialize(HttpApplication application);
    void ReleaseResources();
}

public class PipelineInterceptor : IHttpModule
{
    public void Initialize(HttpApplication context)
    {
        context.PostCacheResolution += InterceptRequestFlow;
    }

    private void InterceptRequestFlow(object sender, EventArgs e)
    {
        // Custom validation or routing logic injected at this specific pipeline stage
    }

    public void ReleaseResources() { }
}

Once preliminary checks complete, the runtime requires a handler capable of generating the actual HTTP response. All request handlers implement IHttpHandler, which defines a single core execution method:

public interface IHttpHandler
{
    void ProcessIncomingRequest(HttpContext ctx);
    bool SupportsReuse { get; }
}

Routing Interception and Data Extraction

The transition from generic ASP.NET processing to MVC routing occurs through the UrlRoutingModule. This component registers globally and hooks into the PostResolveRequestCache event. Its primary responsibility is evaluating the incoming URL against a centralized route collection.

When the module identifies a matching pattern, it extracts routing parameters (typically controller, action, and dynamic segments) into a RouteData container. This container also maintains a reference to a route handler, which dictates how the matched request proceeds:

public void EvaluateRouteMatch(HttpContextBase context)
{
    RouteData matchResult = RouteTable.GlobalRoutes.Resolve(context);
    
    if (matchResult != null && !(matchResult.Handler is RouteBlock))
    {
        var requestCtx = new RequestContext(context, matchResult);
        context.Current.RequestContext = requestCtx;
        
        IHttpHandler executionHandler = matchResult.Handler.CreateHandler(requestCtx);
        
        if (executionHandler == null) throw new MissingHandlerException();
        
        context.RemapHandler(executionHandler);
    }
}

Handler Generation and Controller Resolution

The standard route handler for MVC frmaeworks is MvcRouteHandler. Its responsibility is minimal but critical: instantiate the core HTTP handler that will manage the remainder of the execution pipeline. That handler is MvcHandler.

Inside MvcHandler, the framework performs several initialization steps. It extracts the controller identifier from the route data, delegates instantiation to a factory, and triggers the controller's execution routine:

protected virtual void ExecutePipeline(HttpContextBase ctx)
{
    Security.TrustedExecution(() => 
    {
        IController targetInstance;
        IControllerFactory factory;
        
        PrepareExecutionContext(ctx, out targetInstance, out factory);
        
        try
        {
            targetInstance.Execute(RequestContext);
        }
        finally
        {
            factory.ReleaseController(targetInstance);
        }
    });
}

The IControllerFactory decouples instantiation logic from the pipeline. By default, it utilizes reflection to locate a class matching the requested identifier and constructs an instance, applying any configured dependency injection rules.

Action Method Invocation

Once instantiated, the controller's Execute method runs. Internally, the base implementation delegates action selection and execution to an invoker component. The invoker analyzes available methods, applies filter chains, and executes the target action:

protected virtual void RunActionMethod(RequestContext ctx)
{
    string actionName = RouteData.GetRequiredAction();
    if (string.IsNullOrWhiteSpace(actionName)) 
        throw new MissingActionException();

    IActionInvoker invoker = ActionResolver.GetInvoker() ?? new DefaultActionInvoker();
    invoker.Invoke(ctx, actionName);
}

The ActionInvoker locates the correct method signature, binds incoming request data to parameters, executes authorization/action filters, and finally runs the action code. The execution output is encapsulated within an ActionResult object.

Result Execution and Template Rendering

The ActionResult base class exposes an ExecuteResult method, which dictates how the response payload is formatted. Implementations vary widely, covering JsonResult, RedirectResult, and ViewResult.

When ViewResult is returned, the framework activates a view engine. The engine locates the corresponding template file, compiles it into an executable type, and renders the final markup direct into the HTTP response stream:

public override void GenerateResponse(ControllerContext ctx)
{
    ViewEngineResult engineOutput = null;
    
    if (ResolvedView == null)
    {
        engineOutput = EnginePool.FindView(ctx, TemplateName, LayoutPage);
        ResolvedView = engineOutput?.LocatedView;
    }

    var renderContext = new ViewContext(ctx, ResolvedView, ModelData, TempData);
    ResolvedView.Render(renderContext, ctx.HttpContext.Response.Output);
}

This rendering phase writes the final HTML directly to the output buffer, completing the request-response cycle.