Earlier I posted about changes in ASP.NET Core 1.0 and one of the biggest change is in HTTP pipeline. We as ASP.NET developers are quite familiar with HttpHandler
and HttpModules
but with this new version of ASP.NET, they are gone. They are replaced with a new better, cleaner and easy to implement approach called “Middleware“. You can think of Middleware is a combination of HttpHandler
and HttpModule
. In this post, find out how ASP.NET Core 1.0 Middleware is different from HttpModule.
Before we move to similarities and differences, let’s talk briefly about HttpHandler, HttpModules and Middleware.
HttpHandler
HttpHandler are extension based. They used to handle requests for file name with specific extension, such as .rss. The most common handler is an ASP.NET page handler that processes .aspx files. When users request an .aspx file, the request is processed by the page through the page handler. You can configure them in web.config.
HttpModule
HttpModules are event based. It is called on every request that is made to your application. HTTP modules are called as part of the ASP.NET request pipeline and have access to life-cycle events throughout the request. And they are also configured via web.config or Global.asax.
Middleware
The definition provided by OWIN specification for MiddleWare is closest, in relation to ASP.NET Core 1.0.
Middleware – Pass through components that form a pipeline between a server and application to inspect, route, or modify request and response messages for a specific purpose.
You can think of Middleware as small application components that can be incorporated into an HTTP request pipeline. It is a combination of both HTTP modules and handlers that we’ve had in classic ASP.NET. You can use Middleware to implement various tasks when processing requests such as authentication, session state retrieval and persistence, logging and so on.
Similarity between Middleware and HttpModule
Middlewares are similar to HttpModules as they serve the same purpose. Like modules, middlewares are also executed in every single request, both needs to be configured and can be used to generate their own HTTP response.
Difference between Middleware and HttpModule
HttpModule | Middleware |
---|---|
HttpModules are configured via web.config or global.asax | Middleware are configured via code rather than web.config. ASP.NET Core 1.0 has Startup.cs file (entry point for application) where middlewares are added. |
As a developer, you don’t have control on their order of execution. As order of modules is mainly based on application life cycle events. | Unlike modules, you are in full control of what get’s executed and in what order. As they are executed in the order in which they are added. |
The execution order remains same for requests and responses. | Order of middleware for responses is the reverse from that for requests. |
HttpModules helps you to attach code specific to a application events. | Middleware is independent of these events. |
HttpModules are tied to System.web . |
Middlewares are host independent. |
Built-in Middleware
ASP.NET Core 1.0 is shipped with the following Middleware components.
Authentication | Provides authentication support. |
CORS | Configures Cross-Origin Resource Sharing. |
Routing | Define and constrain request routes. |
Session | Provides support for managing user sessions. |
Routing | Provides support for serving static files, and directory browsing. |
Diagnostics | Includes support for error pages and runtime information. |
Example of Middleware
Create a web application targeting ASP.NET Core 1.0 and open the startup.cs file. In startup.cs, you will find configure method and find similar code. Highlighted lines in below code, are built-in Middleware with ASP.NET Core 1.0.
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) { loggerFactory.AddConsole(Configuration.GetSection("Logging")); loggerFactory.AddDebug(); app.UseApplicationInsightsRequestTelemetry(); if (env.IsDevelopment()) { app.UseBrowserLink(); app.UseDeveloperExceptionPage(); app.UseDatabaseErrorPage(); } else { app.UseExceptionHandler("/Home/Error"); // For more details on creating database during deployment see http://go.microsoft.com/fwlink/?LinkID=615859 try { using (var serviceScope = app.ApplicationServices.GetRequiredService<IServiceScopeFactory>() .CreateScope()) { serviceScope.ServiceProvider.GetService<ApplicationDbContext>() .Database.Migrate(); } } catch { } } app.UseIISPlatformHandler(options => options.AuthenticationDescriptions.Clear()); app.UseStaticFiles(); app.UseIdentity(); // To configure external authentication please see http://go.microsoft.com/fwlink/?LinkID=532715 app.UseMvc(routes => { routes.MapRoute( name: "default", template: "{controller=Home}/{action=Index}/{id?}"); }); }
The configure
method above creates a request pipeline by adding middlewares. It first adds error pages in case of development environment or error handler in case of production environment, then adds support for static files, ASP.NET Identity authentication, and finally, ASP.NET MVC. The thing to note here is, by design for accessing static files (static content in wwwroot
folder) no authentication is required. Therefore, app.UseIdentity();
is added after app.UseStaticFiles();
middleware. If the request is for file other than static files then it will flow to the next piece of middleware which is app.UseIdentity();
.
I recommend all to read the post how to create and configure middleware in ASP.NET Core.
That’s all folks. Keep visiting this blog and share this in your network. Please put your thoughts and feedback in comments section.
Well written article, concept explain in very simple way.
thanks
This article is really awesome. To the point !!!
Very helpful and Great information,
I appreciate advise especially coming from a professional.
Thanks again and keep up the great work!
Well written article, thanks