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

               

Content-Length

Response Buffering at Service[1]

Response Chunked ?

Notes

Main Scenarios

1

StringContent

Known

Not Buffered

Not Chunked

 

2

ByteArrayContent

Known

Not Buffered

Not Chunked

 

3

StreamContent with inner Stream whose length can be calculated

Known

Not Buffered

Not Chunked

Example: MemoryStream, for which we can calculate the length.

4

ObjectContent

Not Known

Buffered

Not Chunked

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.

5

StreamContent with inner Stream whose length cannot be calculated

Not Known

Not Buffered

Chunked

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.

Advanced Scenarios

6

Custom HttpContent deriving from HttpContent

Not Known

Buffered

Not Chunked

Similar behavior as in ObjectContent (#4)

7

Custom HttpContent deriving from HttpContent and which knows its length

Known

Not Buffered

Not Chunked

Similar behavior as in StringContent (#1), ByteArrayContent(#2).

8

Custom HttpContent deriving from StreamContent and with inner Stream whose length can be calculated.

Known

Not Buffered

Not Chunked

Similar behavior as in #3.

9

Custom HttpContent deriving from StreamContent and with inner Stream whose length cannot be calculated.

Not Known

Not Buffered

Chunked

Similar behavior as in #5.

        
[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!.