Thanks for filling this issue!

Reporter@: Could you please help us by providing sample test file , device and screen-cast of the issue for better understanding and triaging further.

Thanks!

Network bug triager here.

Thanks for filing bug with us. ERR_CONTENT_LENGTH_MISMATCH usually indicates that a content-length header is present and the body contains fewer bytes than promised by the header at connection close: either the connection was closed prematurely, or server sent an invalid content-length header. I'm hearing you claim that server sent the correct content-length. In any case, does that work before? Does this app run ok with other browser?

Unfortunately we won't be able to identify what goes wrong in your case as I wasn't able to repro. Collecting a NetLog will help us to identify what really happens on the network layer. Please follow instructions on https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details and let us know once you have that available. Cheers!

If the resource is compressed, you are sending the compressed length, and not the uncompressed length, correct?

Anyhow, if you fail to respond, we can't do anything but close the bug, unfortunately.

I have found the cause of the issue! The root cause of this issue is that chrome is sending request to fetch the favicon resource and produces a pending request forever when server does not respond to the favicon request. But chrome is continuing making new request to the favicon automatically creating a growing stack of pending requests. This results in too many connections configured in the server firewall which finally leads the server to close the connection during sending of a file. 
Chrome should not produce an infinite stack of pending requests for a favicon and stuck itself because of this.