When the proxy receives responses from external servers over a certain size, it has to break those responses apart to avoid holding the entire response body in memory. The proxy switches to use Transfer-Encoding: chunked. While the chunked encoding from the proxy appears to be handled perfectly, FireFox and likely other browser cannot read it successfully. The encoding works on Chrome, however.
This currently applies to files over 81,920 bytes. Interestingly, Flash also appears to handle the encoding fine, as we have yet to see it affect videos.
To reproduce this, perform the following:
1) Start LittleProxy (should be documented on the Wiki)
2) Configure FireFox to point to the proxy IP address and port -- use 127.0.0.1/8080
3) Open a browser page to any file over the above mentioned size, for example:
http://i.i.com.com/cnwk.1d/i/bto/20091023/sandberg.jpg
You should see that with the proxy, the image doesn't appear. If you reconfigure FF to not use the proxy, the image should appear.
Note this was tested with FireFox 3.0.14 on OSX.
src/test/java/org/littleshoot/proxy/HttpProxyTest.java
The test downloads the above file: http://i.i.com.com/cnwk.1d/i/bto/20091023/sandberg.jpg both directly and through the proxy. In the proxy case, it decodes the chunked Transfer-Encoding the proxy adds, and it then verifies the resulting message body is identical to the message body in the direct download, non-chunked case. It is.
So, at least according to the test, Netty chunked encoding is fine. The question is, what's different about the way the test is decoding the chunked encoding and the way FireFox is decoding it?