Message processing pipeline for the Web API

Preface to the message processing pipeline for the Web API

MVC has a mechanism for request processing, and of course the Web API has its own set of message-processing pipelines, which are always done through Httpmessagehandler. We know that the request information exists in the Requestmessage, and the response information exists in Responsemessage, when the request information enters the pipeline, at this time Httpmessagehandler will handle it accordingly, When executed to a method on the controller, the response is now made, and the resulting response information httpresponsemessage is reversed through httpmessagehandler and then processed and eventually returned to the client. The following is a detailed description of the objects in the request pipeline. (If there is something wrong, please haihan).

Httpmessagehandler

This class is the base class for all the objects in the pipeline process, that is, the most important class, and the following we open with the. NET Reflector to see the definition of the class

The class is an abstract class and the two most important methods are Dispose and sendasyc, and for the implementation of the Dispose method, we look at the following:

public void Dispose () {this    . Dispose (1);    Gc. SuppressFinalize (this);    return;} protected virtual void Dispose (bool disposing) {}

is a very standard way to implement resource recovery, but it does not realize the recovery of a resource, the following will be used, first shelved here.

For the second method is SendAsync, see the first parameter of this method is httprequestmessage, we can think of this method is used to handle the incoming request and return the Task

Delegatinghandler

As described above, for the request and response are implemented through Httpmessagehandler, which is equivalent to the end-to-end, but the real implementation of its connected role but Delegatehandler, and the class is not just inheritance, but also some of the corresponding extension, Let's take a look at the definition of the class:

The above important two methods of Dispose and SendAsync as well as the innerhandler fields, below we look at these three.

The first is Dispose, which has been said to have not realized the recycling of resources in Httpmessagehandler, from which we can see that it has been rewritten, indicating that it might have been recycled in its inheritance class Delegatinghandler, just guess, We're clear about the specifics of the implementation. As follows:

protected override void Dispose (bool disposing) {    if (disposing = = null)    {        goto label_0029;    }    if (this.disposed! = null)    {        goto label_0029;    }    this.disposed = 1;    if (This.innerhandler = = null)    {        goto label_0029;    }    This.innerHandler.Dispose (); label_0029:    base. Dispose (disposing);    return;}

It is clear that through this . Handler.dispose (); We know that is the realization of the resource recycling, then what is the Innerhandler field is what, see its return type is Httpmessagehandler, the description is to obtain a reference to the Httpmessagehandler object, This is followed by overriding the SendAsync method in the base class, and calling this method is called through the property Innerhandler. We said that Innerhandler is a reference to the next Httpmessagehandler handler that is more explicit than the reference to get the object Httpmessagehandler.

in the above narrative, Delegatinghandler is the entire message processing pipeline, because the current Delegatinghandler processing the current request is completed, The next one is entrusted to Httpmessagehandler and its reference is given to innerhandler for processing, the entire pipeline is based on Delegatinghandler to achieve, the whole process can be seen as a chain of trust to complete, At the same time the name for the Delegatinghandler surface meaning for the entrusted processing so more aptly expressed the entire process. But we should also note that Innerhandler in Delegatinghandler always refers to the processing of the next request because there is no next handler in the last handler in the pipeline that is the end handler. Therefore, the delegatinghandler is not inherited in the last handler, but inherits from the base class Httpmessagehandler.

For the implementation of the Innerhandler connection to the next Httpmessagehandler-like delegation chain, similar to the following:

        Public ienumerable<string> Gethandlerchain (Delegatinghandler handler)        {            yield return handler. GetType (). Name;            while (null! = handler. Innerhandler)            {                yield return handler. Innerhandler.gettype (). Name;                Handler = handler. Innerhandler as Delegatinghandler;                if (null = = handler)                {break                    ;}}        }

Httpserver

As we've already said above, except that the handler at the end is based on Httpmessagehandler, the rest is based on Delegatinghandler. At the same time, we also talked about the next Httpmessagehandler connected by Innerhandler in the whole pipeline, that is Innerhandler is in the middle of the whole pipe, but which object is the pipe head and pipe end? The pipe head is the next Httpserver object we're going to talk about, since the class is also in the pipeline, and it inherits from Delegatinghandler, let's look at the definition of that class:

The above known Httpserver class is indeed inherited from the delegatinghandler and the most important two properties are the Configuration and Dispatcher, and the two properties are read-only, by looking at the following:

Public httpconfiguration configuration{    get    {        return this._configuration;}    } Public Httpmessagehandler dispatcher{    get    {        return this._dispatcher;    

There are several constructors in the Httpserver class, and when the values of the two properties are explicitly specified, they are initialized in the corresponding constructor, but if the value of the two attribute is not specified, no doubt the default constructor is called. A httpconfiguraion is created as the value of the property configuration, which is known by the default constructor as follows:

Public Httpserver () {This    : ctor (New Httpconfiguration ());    return;}

At this point, the value of the property dispatcher is a Httproutingdispatcher object (the class is the tail in the pipeline, Because the return value of this property is Httpmessagehandler and the Httproutingdispatcher class inherits from Httpmessagehandler. When Httpserver is created, the head and tail in the pipeline are determined in succession. From the configuration file in the Web API, it is known that all configurations are based on httpconfiguration, so if you want to customize handlers in a pipeline that inherits from Delegatinghandler, Registering the custom handler at this point is, of course, a httpconfiguration implementation.

Httproutingdispatcher

The above also makes a little cushion for this class, which is the last Httpmessagehandler in the pipeline, and the object of the class is generated by Httpsever the constructor of the header in the pipeline. This class is defined as follows:

public class httproutingdispatcher:httpmessagehandler{    //Fields    Private ReadOnly httpconfiguration _ configuration;    Private ReadOnly httpmessageinvoker _defaultinvoker;    Methods public    Httproutingdispatcher (httpconfiguration configuration);    Public Httproutingdispatcher (httpconfiguration configuration, Httpmessagehandler DefaultHandler);    private static void Removeoptionalroutingparameters (Idictionary<string, object> routevaluedictionary);    protected override task
This definition of the above also verifies that the tail in the pipeline is inherited httpmessagehandler rather than inherited from Delegatinghandler, because when the Web API requests a URI that is directly requesting a method on the controller, it responds when the method on the controller finishes executing , and Httproutingdispatcher is the last Httpmessagehandler in the pipeline, so find the controller and activate the method on the controller and then reverse the response through the pipeline. The above constructor is known to specify a Httpconfigutaion object when constructing a Httproutingdispatcher object. The Httproutingdispatcher object created by the Httpmessagehandler specified above defaulthandler is to activate the controller and the method.
The above describes several important objects throughout the message pipeline in the Web API:

 
 

  
  
 
   
Pipe Head (httpserver), middle of pipe (Innerhandler in Delegatinghandler), Pipe end (Httproutingdispatcher).
 
  
 
 
Here's an overview of the whole pipe. "Source: Web API Pipeline"
Summarize this section of the Web API is one of the core message processing pipeline to do a little detailed introduction, personally feel that the message pipeline principle to do a basic understanding is necessary, when the need for manual customization in the various pipeline period of the request is not at a loss, hope that through a more detailed introduction can help everyone.
Message processing pipeline for the Web API