Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
ASP.NET Core middleware runs in the application’s HTTP request pipeline; MVC and Razor Pages filters run later, after ASP.NET Core selects an action. Use middleware for broad request-and-response behavior, and choose a filter when work belongs at a particular action-pipeline stage or needs that stage’s framework context.
How middleware and filters fit into a request
A request moves through middleware in the order the application registers the components. A component can do work before and after calling the next component, or stop the request from going farther. As the response returns, the earlier components resume in reverse order. The registration order therefore affects behavior as well as security and performance. See Microsoft’s ASP.NET Core middleware documentation.
For an MVC or Razor Pages endpoint, endpoint execution invokes the applicable framework filter pipeline. Filters run after ASP.NET Core has selected the action to execute. Their position in that pipeline determines which stage they can observe or surround. A filter is not a general replacement for middleware that needs to run elsewhere in the application pipeline. Microsoft describes filter stages and their limits in its ASP.NET Core filters documentation.
Middleware vs. filters at a glance
| Aspect | Middleware | Filters |
|---|---|---|
| Pipeline | Application-wide HTTP request pipeline. | MVC or Razor Pages action-invocation pipeline. |
| When it runs | At the point set by its registration in the application pipeline; it may run before or around endpoint execution, depending on placement. | After action selection, at a framework stage such as authorization, resource handling, action execution, exception handling, or result execution. |
| Context | HTTP pipeline context. | Framework filter context; some filter types can inspect or change action arguments or results. |
| Ordering | Registration order on the request path, then reverse order as the response unwinds. | Filter stage, with scope and order rules within the action pipeline. |
| Typical fit | Behavior that should apply broadly to requests, such as request logging or application-level exception handling. | Behavior tied to an action-pipeline stage, action arguments, results, or result execution. |
| Reach | Requests that pass through the middleware in the configured pipeline. | Supported MVC and Razor Pages flows; support varies by filter type. Filters do not apply directly to Razor components. |
What each filter stage can do
“Filter” covers several different hooks, so the right choice depends on when the code must run. The following stage descriptions reflect Microsoft’s ASP.NET Core 10.0 filters documentation.
#1 Best Overall
Authorization filters
These run first in the filter pipeline and can short-circuit processing when a request is unauthorized.
Resource filters
These run after authorization and can surround the rest of the filter pipeline. The resource-executing stage occurs before model binding, making this stage relevant when work must happen before binding begins.
Rank #2
Action filters
These run immediately before and after a controller action. They can inspect or change action arguments and results, but action filters are not supported in Razor Pages.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Endpoint filters
These run immediately before and after an action or route-handler endpoint and can change arguments and results. They are not supported in Razor Pages.
Rank #3
Exception filters
These handle specified unhandled exceptions during action or result execution. They do not handle exceptions thrown by middleware, routing, or model binding, so they are not a general application-wide exception-handling mechanism.
Result filters
These surround action-result execution and run only when the action method executes successfully.
Razor Page filters
These run before and after a Razor Page handler. Filter support also depends on the application’s endpoint model: filters apply to Razor Pages, API controllers, and controllers with views, but not directly to Razor components. A page, controller, or view that hosts a component can still use a filter in its own supported pipeline.
How to choose the right hook
Choose middleware for behavior outside a specific action
- Use middleware when behavior should cover requests broadly or must run outside the MVC or Razor Pages action lifecycle.
- Use it for application-level concerns such as request logging or exception handling that should cover later pipeline components.
- Place it deliberately: an exception-handling component must be early enough to catch failures in components that run after it.
Choose a filter for a specific framework stage
- Use an action filter for work immediately around a controller action.
- Use a resource filter when the work needs to occur before model binding or surround the remaining filter pipeline.
- Use a result filter when the concern is action-result execution.
- Check that the filter type is supported by the application’s endpoint model, especially when working with Razor Pages or Razor components.
Do not select an exception filter merely because its name sounds like a global error handler. Its documented scope excludes exceptions from middleware execution, routing, and model binding.
Best Value
- Applying all key ASP.NET Core components, including MVC for HTML generation, .NET Core, EF Core, ASP.NET Identity, dependency injection, and more
- Integrating ASP.NET Core with leading client-side frameworks, including Bootstrap
- ASP.NET Core code for implementing business logic and data transformations
- Handling configuration, routing, controllers, views, and common tasks (including posting forms and presenting data)
- Performing complementary tasks: error handling, logging, application design, authentication, localization, and more
Ordering is different in the two pipelines
Middleware order is established in application setup. Each component runs on the way in at its registered position and, if it calls the next component, resumes on the way out in reverse order. Microsoft states: “The order you add middleware components in the Program.cs file defines the order in which the middleware components are invoked on requests and the reverse order for the response.”
Filters are ordered within the action-invocation pipeline, with their stage and filter scope/order rules determining where they run. Because the filter pipeline begins only after action selection, changing filter order does not make a filter observe earlier middleware or routing work.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →
