ASP.NET Core Request Processing Life Cycle

Back to: ASP.NET Core Web API Tutorials

ASP.NET Core Request Processing Lifecycle:

In this article, I will discuss the ASP.NET Core Request Processing Life Cycle with Examples. Please read our previous article discussing ServiceFilter vs TypeFilter in ASP.NET Core Web API Applications. When a client (usually a browser or API client) sends an HTTP request to an ASP.NET Core application, the request passes through several stages before the response is returned. This pipeline is designed to handle routing, authentication, authorization, execution of business logic, response manipulation, error handling, and more. For a better understanding, please have a look at the following diagram:

Client (HTTP Request)

This is the starting point where the client (like a browser, mobile app, or another service) initiates an HTTP request to the server. Could be a browser requesting a webpage, a REST API call, or any HTTP-based client.

Middleware

The request first passes through a series of middleware components. Middleware is a crucial concept in ASP.NET Core, forming a pipeline where each component can inspect, modify, or short-circuit the request/response. The following are some of the Common Middleware Tasks:

• Routing: Determines the endpoint (controller/action) to handle the request.
• CORS (Cross-Origin Resource Sharing): Enabling or blocking requests from other origins.
• Authentication: Validating the identity of the user.
• Static Files: Serving static resources like images, CSS, JS, etc., directly without hitting controllers.
• Exception Handling: Catches unhandled exceptions and produces standardized error responses globally.

Middleware executes sequentially in the order they are registered. After middleware processing, the request proceeds to the routing engine.

Routing Engine (Select Controller & Action)

After middleware, the routing engine examines the incoming HTTP request URL and HTTP method to determine which controller and action will process the request. It maps the incoming route to the corresponding action method.

Authorization Filter (Check User Authentication & Authorization)

After routing determines the target action, Authorization Filters execute. These filters verify whether the user is authenticated and authorized to access the requested resource. If the user fails authorization, the request is short-circuited and a 401/403 response is returned. Examples include [Authorize] attributes.

Resource Filter (Caching, Short-Circuit)

Resource Filters run after authorization. They are responsible for tasks such as caching and short-circuiting the pipeline before the action executes. They can cache responses or stop execution and return a cached result, improving performance.

Action Filter (Input Validation, Logging, Pre-Action)

Before the actual action method runs, Action Filters run. Action filters allow logic to run just before and just after the action method executes. They perform pre-processing tasks such as:

• Validating input parameters.
• Logging the start of action execution.
• Manipulating or preparing data needed by the action.

Action Filters can cancel the execution of the action method if validation fails.

Controller Action (Business Logic)

This is the heart of your application, where your business logic resides. The controller action receives the request, processes the input, interacts with services or databases, and returns a result (usually a response model or view).

Action Filter (Post-Action Logic, Logging, Auditing)

After the action method finishes, Action Filters run again for post-processing. Common tasks include:

• Logging the action completion.
• Auditing user actions.
• Modifying the action result before it is processed by the result filters.

Result Filter (Response Modification, Compression, Add Headers)

Result Filters execute after the action has returned a result, but before the result is executed. They can modify the response, compress data, or add HTTP headers. For example, you might add a custom header for tracking or apply output compression.

Resource Filter (Cache the Response Output)

Resource Filters run again after the result filter, usually to cache the response output for subsequent requests. This helps reduce server load by serving cached responses.

Exception Filter (Exception Handling)

Exception Filters catch unhandled exceptions thrown during the pipeline execution (including middleware, action execution, filters). They provide centralized exception handling and can generate appropriate error responses or perform logging. If an exception occurs, these filters execute to generate a friendly error response.

Client (HTTP Response)

After all filters and processing are complete, the HTTP response is sent back to the client. This response contains the data or error information requested by the client.

ASP.NET Core Request Processing Lifecycle as an Airport Security Check

Client HTTP Request → You are arriving at the airport

Just like you, the passenger, arrive at the airport, the client (browser or API client) initiates a request by arriving at the server. This is the start of the journey, where everything begins.

Middleware → Airport entrance and general security screening

Middleware acts like the initial airport security checkpoints that everyone must pass through. This includes baggage scans, metal detectors, ID verification, and general checks that apply to all passengers regardless of destination. Similarly, ASP.NET Core middleware handles cross-cutting concerns such as:

• Authentication (checking your identity badge)
• CORS (allowing or blocking passengers from other countries)
• Exception handling (catching any issues early)
• Static file serving (like airport signage or info desks)

Middleware is the first line of defense and processing for every request entering the system.

Routing Engine → Checking your flight ticket and deciding on your gate

After clearing general security, the routing engine acts like the ticket counter and gate assignment. The routing engine reads your ticket (HTTP URL and method) and decides which boarding gate (controller and action) you need to go to. This is the decision point that directs your journey further inside the airport.

Authorization Filter → Passport and visa check

Now, before you can board your flight, airport officials verify your passport and visa to ensure you’re authorized to travel to your destination. In ASP.NET Core, the authorization filter checks if the user is authenticated and has permission to access the requested resource. If this check fails, you are stopped and sent back (unauthorized response).

Resource Filter → Special customs or security screening based on your destination

Some passengers have special customs checks or expedited screening (like trusted traveler lanes). Resource filters represent this targeted caching or short-circuiting process. They can decide to bypass further checks if you’re already cleared or provide cached responses to speed up processing.

Action Filter (Pre-Action) → Final boarding preparations

Just before boarding, staff may check your boarding pass one last time, validate your belongings, or provide last-minute instructions. Pre-action filters perform input validation, logging, or other preparatory steps before the core business logic runs.

Controller Action → Boarding the flight and the actual journey

This is the heart of your airport experience—boarding the plane and starting your flight (business logic execution). The controller action handles the main processing of the request, like fetching data, processing transactions, or returning web pages.

Action Filter (Post-Action) → Flight crew’s post-boarding checks

After boarding, the flight crew might do final safety checks or prepare for takeoff. Post-action filters perform tasks like logging, auditing, or modifying the result after the action method completes.

Result Filter → In-flight services and cabin adjustments

Result filters can modify the response, much like in-flight services adjusting your experience—adding announcements, meals, or other enhancements. They may compress the response, add headers, or tweak output before it reaches the client.

Resource Filter (Post-Result) → Caching your flight data for faster future processing

Some information about your journey (flight path, customs clearance) is cached to improve future flights. Post-result resource filters cache the response output to serve similar requests more efficiently later.

Exception Filter → Emergency handling and flight diversions

If something unexpected happens—like an emergency or technical fault—the exception filter acts like the emergency protocols and crew response. It catches exceptions during processing and handles them gracefully, similar to how flight crews manage emergencies to ensure passenger safety.

Client HTTP Response → You are safely reaching your destination airport

Finally, you disembark from the plane and arrive at your destination—this is the HTTP response sent back to the client. It contains the outcome of your journey: success, data, or error information, ready for you to consume.

In the next article, I will discuss Authorization vs Resource vs Action vs Result Filters in ASP.NET Core Web API. In this article, I explain the ASP.NET Core Request Processing Life Cycle with Examples. I hope you enjoy this ASP.NET Core Request Processing Life Cycle article.