ASP. NET Core what's in the HTTP pipeline? asp. netcore

ASP. NET Core what's in the HTTP pipeline? asp. netcore
Preface

It's about to end on March 13, 2016. The time is so fast.

After writing the Identity series last time, the response was good, so I was planning to write an ASP. NET Core middleware series, but I encountered a lot of things in the middle. The first is NPOI porting. After the transplantation, there are still some bugs to be fixed. Then, one thing is a middleware design and development work on message consistency in the distributed architecture, and the blog must insist on writing, finally, there are several books to read and digest, So I deeply feel that time is not enough. Let's get started with theme.

Most of the middleware relies on the context provided by the HTTP pipeline and httpjavasactions. Therefore, it is necessary to first introduce what ASP. NET Core encapsulates in the pipeline. After understanding it clearly, it will help you to learn more advanced. It doesn't matter if you don't understand them. You can understand these concepts. You don't need to be proficient in what you have done in each step. I think that as you develop more and more things, you will naturally want to know more about these things. At that time, you will see the source code.

IApplicationBuilder

IApplicationBuilderThe Configure method is located in the Startup. cs file.

public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory){    app.UseDeveloperExceptionPage();    app.UseStaticFiles();    app.UseMvc();}

IApplicationBuilder is just like its name. In fact, it is very simple. It encapsulates an interface internally and provides an extension to the outside world. Specifically, it is

Encapsulated internally

• IServiceProvider ApplicationServices { get; set; }: The services used by the application are those injected by ConfigureServices.
• IFeatureCollection ServerFeatures { get; }:ToolboxObject.
• IDictionary<string, object> Properties { get; }: Data is shared across various middleware.

Expanded externally

• IApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware): Register Middleware

Another Build is used to return the final HttpContext status of the MPs queue.

• RequestDelegate Build();: Final RequestDelegate form

There is nothing complicated, so we need to understand these things. Below isIApplicationBuilderIt looks more intuitive.

So what is RequestDelegate?

RequestDelegate

RequestDelegate is a delegate that encapsulates HttpContext in the form of delegation. It is also a very important object in ASP. NET Core. Let's take a look at the definition.

namespace Microsoft.AspNetCore.Http{    public delegate Task RequestDelegate(HttpContext context);}

Why is this object very important? Because all the middleware in the pipeline uses it directly or indirectly for some functions, because it encapsulates the HttpContext, httpContext is so high in Web development. Next let's talk about it.HttpContext.

HttpContext

HttpContext should be the most familiar object for Web development. In this object, it encapsulates the key object information in the Http entire pipeline, which is also transmitted throughout the pipeline, that is, it will go through the entire request lifecycle, so this object is very important and a basic knowledge of Web development.

Compared withSystem.Web.HttpContextIn ASP. NET Core, HttpContext isAbstract class, Located inMicrosoft.AspNetCore.HttpUnder the namespace. It has a default implementation calledDefaultHttpContextLocated in Microsoft. AspNetCore. Http assembly.

We know how the previous System. Web. HttpContext was created?

In traditional ASP. NET Program, after IIS receives the request, it will be handed over to the aspnet_isapi.dll assembly, the Assembly starts ASP.. NET runtime environment, and then calls ISAPIRuntime for encapsulation. After encapsulation, it is an HttpWorkRequest object, which is then converted into an HttpContext by HttpRuntime.

Therefore, in System. Web. HttpContext, the constructor isHttpWorkerRequest

namespace System.Web{    public sealed class HttpContext : IServiceProvider, IPrincipalContainer    {        public HttpContext(HttpWorkerRequest wr);    }}

That is to say, all the information for building HttpContext is transmitted by IIS.HttpWorkerRequest.

Now, forget about it. Yes, forget it all. At this time, you have to scold Microsoft again. Nima didn't know how many times it had been backed up for an interview. ===

There is no way. We also need to constantly learn the development and progress of the times. In ASP. NET Core, how does one generate HTTP context without IIS? How does one obtain the information required to build HttpContext? Do not worry. Let me break it down slowly.

IFeatureCollection

Here we need to talk about another important interface, which isIFeatureCollectionInterface. What does this interface do? Let's take a look at its definition:

public interface IFeatureCollection : IEnumerable<KeyValuePair<Type, object>>{    bool IsReadOnly { get; }    int Revision { get; }    object this[Type key] { get; set; }    TFeature Get<TFeature>();    void Set<TFeature>(TFeature instance);}

The definition of this interface should be able to understand its functions. The interface inherits fromIEnumerable<KeyValuePair<Type, object>>This indicates that the interface is a set of key-value pairs. Let's give the interface a name called"Toolbox".

Some people should have guessed that, yes, building HttpContext in ASP. NET Core means that all required components come fromToolbox, ThenToolboxWhat is in it? You can see that the Toolbox containsIHttpRequestFeature,IHttpResponseFeature,ISessionFeatureThere are many other tools that will not be listed one by one. It is precisely because of the tools in the toolbox that finally build the entire HttpContext object. Let's take a look at the constructor of the HttpContext object:

namespace Microsoft.AspNetCore.Http{    public class DefaultHttpContext : HttpContext    {        public DefaultHttpContext(IFeatureCollection features)        {             Initialize(features);        }    }}

That's right. Some may ask, when will these tools in the toolbox be initialized? Don't worry. Let's take a look at the requests and Response we are familiar.

HttpRequest

Similarly, in ASP. NET Core, HttpRequest has become an abstract class. Its default implementation isDefaultHttpRequestIt is mainly used to encapsulate various data requested by the browser to the server, including the URL requested by the browser, and query string data or form data...

I will not go into details here, but it is very simple.

HttpResponse

HttpResponse also becomes an abstract class. Its default implementation isDefaultHttpResponseIt is a common object used to process the returned results after the server receives a browser request.

ASP. NET Core Pipeline

It's time to explain the aboveToolboxThe initialization problem occurs. I think I can use a diagram to directly describe that the requests in the pipeline are no longer appropriate. The following is a flowchart of building the pipeline for the ASP. NET Core server:

As you can see, RequestDelegate carries HttpContext all the way through a variety of servers, Hosting and so on, and finally reaches the Application pipeline region built by IApplicationBuilder, and then goes through various middleware processing, finally, our Response is built, and ourToolboxIt is also in this process that it becomes "full.

One thing you need to know is how to add or register middleware in the pipeline? How is it applied?

As shown in the figure above, the Application pipeline in the orange area is built by IApplicationBuilder. That is to say, we can add our middleware in IApplicationBuilder. Yes, IApplicationBuilder exposesIApplicationBuilder Use(Func<RequestDelegate, RequestDelegate> middleware);Method To let us register the middleware, that isStartup.csFile.

So how is it applied?IApplicationBuilderThere is an IApplicationBuilderFactory object in Hosting. After Hosting is created through this Factory, it will be passed to the HostingApplication object, finally, the IWebHost object calls the Start of the IServer object and passes the HostingApplication to Start the server. You can take a look at the figure above.

Summary

In this article, we know several objects in the ASP. NET Core Http pipeline. They areIApplicationBuilder,RequestDelegate,HttpContext,HttpRequest,HttpResponse,IFeatureCollectionAnd then we know the relationship between them. Then we know the call relationship through a pipeline flowchart and how to register middleware with the pipeline.

In general, the content in this article is abstract, and it takes me a lot of time to write this article. If you think it is helpful to you, thank you for the [recommendation] in the lower right corner ].

Address: http://www.cnblogs.com/savorboard/p/aspnetcore-http-pipeline.html
Author's blog: Savorboard
You are welcome to repost it. Please provide the source and link clearly
 
 

Reference page: http://qingqingquege.cnblogs.com/p/5933752.html