Question

Can I simply set the Transfer-Encoding header?

Will calling Response.Flush() at some point cause this to occur implicitly?

---

EDIT
No, I Cannot call Response.Headers.Add("Transfer-Encoding","anything"); That throws.

any other suggestions?

---

Related:
Enable Chunked Transfer Encoding in ASP.NET

Answer 1

TL;DR: Specifying the content-length is the best way to achieve a fast first byte; you’ll allow chunking at TCP rather than HTTP level. If you don’t know the content-length, setting context.Response.BufferOutput to false will send output as it’s written the the output stream using chunked transfer-encoding.

---

Why do you want to set Transfer-Encoding: chunked? Chunked transfers are essentially a work-around to permit sending documents whose content-length is not known in advance. ASP.NET, however, by default buffers the entire output and hence does know the overall content length.

Of course, HTTP is layered over TCP, and behind the scene TCP is “chunking” anyhow by splitting even a monolithic HTTP response into packets – meaning that if you specify the content-length up front and disable output buffering, you’ll get the best latency without requiring HTTP-level chunking. Thus, you don’t need HTTP-level chunking to provide a fast first byte when you know the content-length.

Although I’m not an expert on HTTP, I have implemented a simple streaming media server with seeking support, dynamic compression, caching etc. and I do have a reasonable grasp of the relevance of a fast first byte – and chunking is generally an inferior option if you know the content-length – which is almost certainly why ASP.NET won’t let you set it manually – it’s just not necessary.

However, if you don’t know the HTTP content length before transmission and buffering is too expensive, you turn off output buffering and presumably the server will use a chunked transfer encoding by necessity.

When does the server use chunked transfer encoding? I just tested, and indeed if context.Response.BufferOutput is set to false, and when the content length is not set, the response is chunked; such a response is 1-2% larger in my entirely non-scientific quick test of a 1.7MB content-encoding: gzip xml document. Since gzip relies on context to reduce redundancy, I’d expected the compression ratio to suffer more, but it seems that chunking doesn’t necessarily greatly reduce compression ratios.

If you look at the framework code in reflector, it seems that the transfer encoding is indeed set automatically as needed – i.e. if buffering is off AND no content length is known AND the response is to an HTTP/1.1 request, chunked transfer encoding is used. However, if the server is IIS7 and this is a worker request (?integrated mode?), the code branches to a native method – probably with the same behavior, but I can’t verify that.