Response buffering & chunking in Web Host scenarios

NOTE: The following table represents the behaviors that are part of Release Candidate(RC) version only. It does NOT represent data for currently in development bits.

What is Chunked Transfer Encoding: This represented by the header “Transfer-Encoding: chunked” indicates that a Request/Response does not know the Content Length of the body that it is going to generate upfront. This header enables to send data the moment it is available instead of the normal flow that a client/service does, which is to buffer the entire content and then send it. Since buffering big content is expensive, this header could be used to send data in chunks the moment it is ready.

[1] – By “Response Buffering at Service” , I mean the buffering ability provided by the hosting layers (ex: IIS/ASP.NET in case of Web Host scenarios).

One of the main things that we try to do is to not double buffer the response content if we already know that a content has been buffered in the upper layers of the stack. (Example: Action is returning a HttpResponseMessage having a StringContent). We depend on the Content-Length header of the response content to figure out if a content has already been buffered or not. For example, If you notice the above table, all the content types for which we know the Content Length, we do not buffer again.

ObjectContent is Buffered : This is important because it enables to provide a good user experience in case when MediaTypeFormatters throw exceptions while writing to a stream.

NOTE: I deliberately left out these details for Self Host scenarios, because the above behaviors are not in symmetry with Self Host. I will create a new post in future for Self Host specifically.

Have fun!.