IIS & Chrome: failed to load resource: net::ERR_INCOMPLETE_CHUNKED_ENCODING

Question

I recently came across a Chrome issue which I think is worth sharing it with you.

I worked on a self written API using an HttpHandler which primary should return json data. But when an error occures I wanted to display an html file. That worked pretty well in IE and FF, but not in Chrome.

Looking to the developer tools revealed this error: net::ERR_INCOMPLETE_CHUNKED_ENCODING

Google said not very much about this issue while it was seen very much. All I got to know was, that it was magically disappearing after some time.

I found out it lays on this lines of code:

result.StoreResult(context);
context.Response.Flush();
context.Response.Close(); //<-- this causes the error

After removing the last line it worked well. I don´t know why only Chrome had/has an issue with that, but it seemed as if I closed the response stream before chrome finished reading it.

I hope it helps those of you coming across the same or a similar issue.

Now my question: How is the best pratice in closing/flushing the response stream? Are there any rules?

Answer 1

According to ASP.NET sets the transfer encoding as chunked on premature flushing the Response:

ASP.NET transfers the data to the client in chunked encoding (Transfer-Encoding: chunked), if you prematurely flush the Response stream for the Http request and the Content-Length header for the Response is not explicitly set by you.

Solution: You need to explicitly set the Content-Length header for the Response to prevent ASP.NET from chunking the response on flushing.

Here's the C# code that I used for preventing ASP.NET from chunking the response by setting the required header:

protected void writeJsonData (string s) {     HttpContext context=this.Context;     HttpResponse response=context.Response;     context.Response.ContentType = "text/json";     byte[] b = response.ContentEncoding.GetBytes(s);      response.AddHeader("Content-Length", b.Length.ToString());      response.BinaryWrite(b);     try     {         this.Context.Response.Flush();         this.Context.Response.Close();     }     catch (Exception) { } } 

Answer 2

I was running into this error when generating a file and pushing it to the user for download, but only occasionally. When it didn't fail, the file was consistently 2 bytes short. Close() forcibly closes the connection, whether it's finished or not, and in my case it was not. Leaving it out, as suggested in the question, meant the resulting file contained both the generated content as well as the HTML for the entire page.

The solution here was replacing

context.Response.Flush(); context.Response.Close(); 

with

context.Response.End(); 

which does the same, but without cutting the transaction short.

Answer 3

In my case, the problem was cache-related and was happening when doing a CORS request.

Forcing the response header Cache-Control to no-cache resolved my issue:

[ using Symfony HttpFoundation component ]

<?php
$response->headers->add(array(
   'Cache-Control' => 'no-cache'
));