Response与Transfer-Encoding:chunked、Content-Length、Content-Encoding:gzip

曾经在公司里的百科留下了一些文章，在地址栏index.php/后加上All，即"index.php/All"后出现的内容至这个时刻或许大多数都是我留下的文档。
别人有两次问过一些知识，现随自己时间安排把一些有用的通用技术文档贴到blog上，以下是一篇(字体大小请调浏览器)：

在j2ee web结构里http header中的 Content-Length 或Transfer-Encoding:chunked
应由web容器层自动设置，不用在应用的servlet里做，因为应用的servlet返回后，还可能经过filter/mod_jk等很多层，
servlet自己是不知道确对的Content-Length，servlet或servlet上的框架只管向response的OutputStream write即可。

Content-Length 和 Transfer-Encoding:chunked是不会在header中同时存在的。

如果是普通地使用response的OutputStream，web容器可能会选择用Content-Length、Transfer-Encoding:chunked 任一方式返回前端。Content-Length会优先点。

如果servlet强硬地调用了OutputStream.flush()，web容器是不知道怎么返回Content-Length的，所以会用Transfer-Encoding:chunked方式返回。

如果servlet中设定了Content-Length，web容器就不用Transfer-Encoding:chunked方式。

如果servlet中设定了Transfer-Encoding:chunked，web容器会保留Transfer-Encoding:chunked，并撒手不管了。

对于一些页面渲染/装饰框架，在先识别了应该先发送的内容后，发送部分数据后，可能立刻调用flush()，可令前端显示页面快点。

如还有Content-Encoding:gzip，Transfer-Encoding是包在Content-Encoding:gzip的外层。从http协议先驱谨慎定的英文，或许就可以看出一些本意：Transfer是针对http header外的http body的，而Content是http body内的。

对于Transfer-Encoding:chunked的数据传到HttpClient，从HttpClient.getResponseBodyAsStream()里获得的数据是已经被拼接起来了的(因为使用者应该没这个奢好，自动解码比较人性化)。如果您提供给getResponseBodyAsStream().read()的存放区比原来chunk大，每次read到的可能会是原来的chunk大小。