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.
Response Content Type
Response Buffering at Service
Response Chunked ?
StreamContent with inner Stream whose length can be calculated
Example: MemoryStream, for which we can calculate the length.
Response is not chunked here because the Server will buffer the entire ObjectContent response, which results in knowing the Content-Length, in which case chunking is no longer required.
StreamContent with inner Stream whose length cannot be calculated
Since we do NOT know the content-length upfront + it’s a StreamContent(we special case this content type), we do not buffer it and hence chunked encoding is used.
Custom HttpContent deriving from HttpContent
Similar behavior as in ObjectContent (#4)
Custom HttpContent deriving from HttpContent and which knows its length
Similar behavior as in StringContent (#1), ByteArrayContent(#2).
Custom HttpContent deriving from StreamContent and with inner Stream whose length can be calculated.
Similar behavior as in #3.
Custom HttpContent deriving from StreamContent and with inner Stream whose length cannot be calculated.
Similar behavior as in #5.
 – 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.