Message Processing pipeline of ASP. NET Web API: HttpMessageHandler Pipeline

The entire ASP. NET Web API Server framework adopts a pipeline design. This "" pipeline is essentially an ordered combination of HttpMessageHandler. This is a "two-way pipeline", with request messages in the opposite direction and response messages flowing in this pipeline at the same time. For an HttpMessageHandler with an intermediate position, after the current HttpMessageHandler completes processing the request, it will pass the processed request to itself. It is defined that the request message processing operation will directly act on the request message. Once the processing is complete, the processed request will be passed back. The Processing Method for response messages in the opposite direction is similar. [This Article has been synchronized to How ASP. NET Web API Works?]

Directory
I. HttpMessageHandler
2. DelegatingHandler

The ASP. NET Web API Server framework is composed of a group of HttpMessageHandler connected by the beginning and end. The pipeline design makes the framework highly scalable. Although the ASP. NET Web API Server framework is used to process requests and responses, the specific processing policies vary with specific scenarios. It is impossible and unnecessary to create a "omnipotent" processor to satisfy all request processing scenarios. Therefore, it is better to have a processor only responsible for a single message processing function. In specific application scenarios, we can select the desired processor based on the specific message processing requirements and form a complete message processing pipeline. Here, the processor used to complete a single message processing function is HttpMessageHandler.

Here, "message processing" has two meanings: targeted processing and based processing. HttpMessageHandler, which is designed to implement a single message processing function, directly or indirectly inherits the abstract type HttpMessageHandler defined below. In the previous introduction to "URL routing", we have mentioned ASP. NET Web API uses the HttpRequestMessage and HttpResponseMessage types to indicate the request messages and response messages processed by the pipeline, respectively. Therefore, the definition of HttpMessageHandler is well understood.

    HttpMessageHandler : IDisposable

 {

       Dispose();

        Dispose( disposing);

       Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken);

 }

As shown in the code snippet above, the abstract class HttpMessageHandler only defines a unique protected abstract method SendAsync, An Asynchronous Method Designed Based on "Paralle Programing. The request parameter indicates the request message that is passed to the current HttpMessageHandler for processing. This is an HttpRequestMessage object. Another cancellationToken parameter is a CancellationToken object that sends the cancel Operation signal. If you have a basic understanding of parallel programming in. NET, I believe you should be familiar with this object.

The processing of request messages and response messages is also reflected in the SendAsync method. Specifically, request message processing is directly implemented in the SendAsync method, while Response Message Processing is completed through the return value. This is an object of the Task Type <HttpResponseMessage>. The "flow" of the message processing pipeline consisting of HttpMessageHandler and the request message and response message in the pipeline can be basically shown in the right figure.

The abstract class HttpMessageHandler implements the IDisposable interface, which implements the Dispose method in a "standard" way. As shown in the following code snippet, no resource recycling is performed when the Dispose method is called ..

    HttpMessageHandler : IDisposable

 {

       Dispose()

     {

         .Dispose();

         GC.SuppressFinalize();

 }

        Dispose( disposing)

     {}

 }

 

We can say that the entire message processing pipeline of ASP. NET Web API is formed by a set of ordered HttpMessagHandler "first and last connections". The specific implementation of "series" is achieved through the DelegatingHandler type. As the name implies, DelegatingHandler has the delegate function. After a task is completed, a third party can be entrusted for subsequent work. If the delegated user is also a DelegatingHandler, can it form a delegation chain? Isn't this delegated chain a message processing pipeline composed of DelegatingHandler?

As shown in the following code snippet, DelegatingHandler is an abstract class inherited from the HttpMessageHandler class. As we mentioned above, the delegated third party is represented by its attribute InnerHandler. The corresponding type is HttpMessageHandler (not DelegatingHandler ). DelegatingHandler overrides the abstract method SendAsync defined in its class. In fact, in addition to directly calling the method with the same name as the InnerHandler attribute, no substantive operations are completed.

    DelegatingHandler : HttpMessageHandler

 {  

        Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken);

      HttpMessageHandler InnerHandler get;  set; }

 }

As mentioned above, if ASP. the message processing pipeline of the NET Web API is composed of DelegatingHandler (except HttpMessageHandler at the end of the pipeline). We can reference another delegate DelegatingHandler based on its InnerHandler, form a chain structure shown on the right.