What are differences between ASP.NET4 and ASP.NET5 Http pipelines?

517 Views Asked by At

I have had a read on what's new in .NET4.6 and one of the things is ASP.NET 5 which I am quite excited about.

One of the new things is New modular HTTP request pipeline, however there is no more info on how exactly is it going to change.

The only reference in the article is

ASP.NET 5 introduces a new HTTP request pipeline that is lean and fast. This pipeline is modular so you can add only the components that you need. By reducing the overhead in the pipeline, your app will experience better throughput. The new pipeline also supports OWIN.

What are major differences between ASP.NET4.5 and ASP.NET5 Http pipelines? How modularity will be controlled?

1

There are 1 best solutions below

0
On BEST ANSWER

The biggest difference in my opinion is the modularity of the new request pipeline. In the past, the application lifecycle followed a relatively strict path that you could hook into via classes implementing IHttpModule. This would allow you to affect the request, but only at certain points along the way by subscribing to the different events that occur (e.g. BeginRequest, AuthenticateRequest, etc.).

The full descriptions of these can be found on MSDN: IIS 5 & 6 or IIS 7, and a walkthrough of creating such a module can be found here.

In the new ASP.NET 5 world, the request pipeline is decoupled from System.Web and IIS. Instead of a pre-defined path, it uses the concept of middleware. If you are familiar with OWIN, the idea is nearly identical, but the basic idea is that these Middleware Components are registered and then the request passes through them in the order that they are registered.

Each middleware component is provided a RequestDelegate (the next middleware component in the pipeline) and the current HttpContext per-request. On each request, the component is invoked, and then has the opportunity to pass the request along to the next in the chain if applicable. For example, an authentication component might opt not to pass the request along to the next component if authentication fails. Using this system, you can really handle a request any way you choose, and can be as light-weight or as feature-rich as you need it to be.

This example is a little bit dated now (e.g. IBuilder has been renamed to IApplicationBuilder), but it is still a great overview of how building and registering these components looks.