From Browser to Controller: Understanding the ASP.NET Core Request Pipeline using Airport Journey Analogy

Have you ever wondered what happens inside an ASP.NET Core application before it handles its very first HTTP request? Before the application can process even a single request, ASP.NET Core performs several startup tasks to prepare the entire environment. Once everything is ready, each incoming request travels through the Request Pipeline.

I believe the airport journey is a good analogy for understanding the ASP.NET Core Request Pipeline. To make this easier to understand, the explanation is divided into two phases:

Airport Preparation Phase (Application Startup)
Passenger Journey Phase (Request Processing)

Let's explore both phases one by one and understand what happens behind the scenes at each step

1. Airport Preparation Phase (Application Startup)

Before an airport can allow even a single passenger to board a flight, a tremendous amount of preparation happens behind the scene.

Early in the morning, airport staff arrive long before the passengers. Security officers take their positions, baggage scanning machines are powered on and tested, boarding gates are prepared, flight information systems are activated, airline staff open their counters, and all checkpoints are made ready. The airport management ensures that every required service is available so that passengers can move smoothly through the airport once it opens.

Only after all these preparations are complete does the airport open its doors to passengers.

ASP.NET Core follows exactly the same approach.

When the application starts, it does not immediately begin processing HTTP requests. Instead, it first prepares the entire environment.

Let’s see how ASP.NET Core performs this preparation in the Program.cs file, as shown below:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.UseExceptionHandler();
app.UseHttpsRedirection();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();
app.Run();

The following points summarize what happens during application startup:

WebApplication.CreateBuilder(args) creates the application builder and prepares the host configuration, configuration sources, logging, and dependency injection container.
builder.Build() builds the application by creating the middleware pipeline.
Each app.Use...() call registers a middleware in the order in which it should execute for every incoming request.
app.MapControllers() registers all controller endpoints so that the routing system knows where requests should be directed.
Finally, app.Run() starts the Kestrel web server and begins listening for incoming HTTP requests.

This is similar to airport staff preparing every checkpoint before the airport opens. No passenger can enter until everything is ready.

Once app.Run() executes, Kestrel starts listening for requests. Now the airport doors are open, and passengers can begin arriving. The second phase starts here.

2. Passenger Journey Phase (Request Processing)

Imagine you have already booked your flight and reached the airport. Even though you have a valid ticket, you cannot directly walk into the aircraft. You must pass through several checkpoints in a specific order. First, your identity is verified. Then, your baggage is scanned during the security screening. Next, your boarding pass is checked at the boarding gate. Only after successfully completing every checkpoint are you allowed to board the aircraft. If you fail at any checkpoint — for example, if your identity cannot be verified or you fail the security screening — you are stopped immediately and cannot proceed further.

Just as a passenger must successfully pass through multiple checkpoints before boarding a flight, every HTTP request must pass through several processing stages before reaching the application endpoint.

The following table compares the airport journey analogy with the ASP.NET Core Request Pipeline:

Following diagram will give you a big picture about on the ASP.NET Core Request Pipeline.

Let’s walk through each checkpoint shown in above diagram and understand what actually happens behind the scenes.

Step 1 — Browser Sends HTTP Request

Just as a passenger arrives at the airport entrance, a browser sends an HTTP request to the application’s URL.

User’s URL example: https://localhost:5011/api/products/2

Browser takes required information like URL, HTTP Method (GET, POST, etc.), Headers etc. This request is then sent to the web server.

Step 2 — Kestrel Receives the Request

Airport analogy: The passenger enters the airport through the main entrance.

ASP.NET Core Web Server: Kestrel is the default web server in ASP.NET Core. Think of Kestrel as the receptionist standing at the airport entrance. Every time a passenger arrives, the receptionist welcomes them, creates their visitor record (HttpContext), and sends them through the predefined security checkpoints (the middleware pipeline).

Note: What is HttpContext?

HttpContext is an object created once by Kestrel for every incoming HTTP request. Initially, it contains only the information available from the HTTP request (such as the request method, path, headers, and an empty response object). As the request moves through the middleware pipeline, each middleware can read from it and add or update information in the same HttpContext instance.

Think of HttpContext as a shared folder that travels with the request. Every middleware receives the same folder. Some middleware only read information from it, while others add new information that later middleware can use.

Initially, it looks something like this:

HttpContext
    Request
        Method = GET
        Path = /api/products/2
        Headers = Authorization...
    Response
        StatusCode = 200 (default)
    User/Authentication = Empty
    Endpoint =    NULL
    Items =   Empty

After passing through all the middleware components, the HttpContext is populated with the required information, as shown below:

HttpContext
    Request
        Method = GET
        Path = /api/products/2
    Response
        StatusCode = 200
    User
        Name = Snesh
        Role = Admin
    Endpoint
        ProductsController.GetProducts()
    Route Values
        id = 2
    Items
    (Any custom values added by middleware)

Does every middleware get a different HttpContext?

Answer: No, A single HttpContext instance is created by Kestrel for each incoming HTTP request. The same instance is passed through the entire middleware pipeline. Middleware can read existing information, modify it, or add new data such as endpoint metadata, route values, user claims, or custom items. This shared context enables middleware components to work together throughout the lifetime of the request.

Step 3 — Exception Handling Middleware (Optional)

Airport analogy: A help desk is available throughout the airport journey. If any unexpected problem occurs at a checkpoint, passengers are guided to the help desk instead of the entire airport operation coming to a halt.

ASP.NET Core: This middleware wraps all the remaining middleware in the request pipeline inside a try-catch block. It doesn’t validate the request itself. Instead, it waits for downstream middleware (such as Routing, Authentication, Authorization, or the Controller) to execute. If any of them throws an unhandled exception, control returns to this middleware, which logs the error and generates a standard error response (typically HTTP 500) instead of allowing the application to crash.

Step 4 — HTTPS Redirection Middleware (Optional)

Airport analogy:
A security officer ensures every passenger enters the airport through the designated secure entrance. If someone attempts to enter through an unauthorized entrance, they are directed to the correct secure entrance before proceeding further.

ASP.NET Core:
If an incoming request uses HTTP (for example, http://localhost), this middleware automatically redirects it to the secure HTTPS URL (for example, https://localhost) before the request continues through the remaining middleware.

Step 5 — Routing Middleware

Airport analogy:
Airport staff check your boarding pass and identify the correct departure gate.

ASP.NET Core:
Matches the incoming request to the appropriate endpoint and stores it in HttpContext. It identifies which controller action should handle the request but does not execute it.

Step 6 — Authentication Middleware

Airport analogy:
Identity verification. Airport staff verifies the passenger’s identity before allowing them to proceed.

ASP.NET Core:
Asks, “Who is this user?” It validates the user’s credentials (such as JWT, Cookie, OAuth, or OpenID Connect). If authentication succeeds, the user’s identity is stored in HttpContext.User.

HttpContext.User
         Name = Snesh
         Role = Admin
         IsAuthenticated = true

Step 7 — Authorization Middleware

Airport analogy:
Boarding pass verification. Even after your identity has been verified, the airline staff checks whether your boarding pass allows you to board the flight. If everything is valid, you are allowed to proceed. Otherwise, you are stopped at the boarding gate.

ASP.NET Core:
Checks whether the authenticated user has permission to access the requested resource. If authorized, the request continues; otherwise, 403 Forbidden is returned.

Authenticated User
Role = User
      │
      ▼
[Authorize(Roles = "Admin")]
      │
      ├── Yes ──► Continue to Controller
      │
      └── No ───► 403 Forbidden

Step 8 — Endpoint Executes

Airport analogy:
Boarding begins. The passenger reaches the assigned gate and boards the correct flight.

ASP.NET Core:
The selected controller action executes, processes the request, and returns an HTTP response.

Routing Selected
ProductsController.GetProduct()
        │
        ▼
Controller Executes
        │
        ▼
HTTP Response

Step 9 — Response Travels Back

Airport analogy:
The passenger successfully boards the aircraft.

ASP.NET Core:
The response doesn’t magically jump back. Instead, it travels through the middleware pipeline in reverse order.

Controller
      ↑
Authorization
      ↑
Authentication
      ↑
   Routing
      ↑
    HTTPS
      ↑
Exception Handler
      ↑
   Kestrel
      ↑
   Browser

Each middleware gets another chance to inspect or modify the response before it reaches the client.

Conclusion

The ASP.NET Core Request Pipeline is the heart of every ASP.NET Core application. Every HTTP request passes through a sequence of middleware before reaching the controller, and the response returns through the same pipeline. Understanding the purpose and order of each middleware helps us build, debug, and maintain secure and efficient applications.

While learning ASP.NET Core, I found that understanding the Request Pipeline became much easier when I visualized it as an airport journey. I hope this analogy helps you build the same mental model and makes it easier to understand what happens behind the scenes — from application startup to processing an HTTP request.

If this article helped clarify the Request Pipeline for you, then it has achieved its purpose. Happy learning!