Commented Issue: TransferEncodingChunked=true doesn't work on WebHost [1124]

When setting response.Headers.TransferEncodingChunked, the response doesn't get chunked, and a client (Fiddler) will fail trying to read the response.

Repro 1:
public HttpResponseMessage Get()
{
HttpResponseMessage response = new HttpResponseMessage(HttpStatusCode.OK);
response.Headers.TransferEncodingChunked = true;
response.RequestMessage = Request;
return response;
}

Repro 2:
public HttpResponseMessage Get()
{
HttpResponseMessage response = new HttpResponseMessage(HttpStatusCode.OK);
response.Content = new LazyContent();
response.Headers.TransferEncodingChunked = true;
response.RequestMessage = Request;
return response;
}

public class LazyContent : HttpContent
{
protected override Task SerializeToStreamAsync(Stream stream, TransportContext context)
{
stream.WriteByte(0);
return Task.FromResult<object>(null);
}

protected override bool TryComputeLength(out long length)
{
length = 0;
return false;
}
}

Comments: The buffer policy of the host correctly/smartly handles the situation of whether a response should be chunked or not based on the existing logic…so ideally the user needn’t set the chunked encoding property explicitly… For example: if the content is already buffered (ex: downloading a file from the disk), then according to our policy, we do not send it chunked as we already know the content-length...in this case using chunked transfer encoding doesn’t make sense…If I remember correctly, we are supposed to send chunked encoding only when we do not know the content length upfront...for example, if we are streaming data from the service to the client as the data is received at the service from some other party (PushStreamContent example)…in case of PushStreamContent, we correctly set the chunked encoding header… So, for any custom httpcontent that user creates, they would need to extend the buffer policy to either send data in chunked or non-chunked.