Tomcat 中响应头信息(Http Response Header) Content-Length 和 Transfer-Encoding 之种种

最新推荐文章于 2024-08-15 17:15:27 发布

谐音太郎

最新推荐文章于 2024-08-15 17:15:27 发布

阅读量2.4w

点赞数 1

分类专栏：服务器系统架构 Tomcat那点事儿文章标签： tomcat header buffer 浏览器手机

本文链接：https://blog.csdn.net/shootyou/article/details/6135669

版权

本文探讨了Tomcat服务器在响应客户端请求时，如何根据Content-Length和Transfer-Encoding头信息处理数据传输。内容包括：1) 客户端在收到带有Content-Length头的响应时，会等待指定长度数据后再解析；2) 当使用Transfer-Encoding:chunked时，数据被分块传输，客户端可边接收边解析；3) Tomcat中，autoFlush属性控制何时向客户端发送数据，影响Content-Length的计算；4) 调用out.flush()会导致Content-Length无法计算，转为使用Transfer-Encoding:chunked。

摘要由CSDN通过智能技术生成

欢迎转帖，But请注明出处谢谢: http://blog.csdn.net/shootyou/archive/2011/01/13/6135669.aspx

先说说原理：

客户端（PC浏览器或者手机浏览器）在接受到Tomcat的响应的时候，头信息通常都会带上Content-Length ，一般情况下客户端会在接受完Content-Length长度的数据之后才会开始解析。而在Tomcat上，页面处理过程中会将需要out.print的数据都放在缓存中，然后一次性的返回给客户端。

另外一种情况就是头信息中不存在Content-Length ，取而代之的是Tansfer-Encoding:chunked ，这个头信息的的意思是response的内容会被Tomcat分成一块一块的发送，客户端也就不需要等到内容都传输完毕了才解析其中的内容。因为这个时候被传送的数据长度是无法预计的，所以存在Tansfer-Encoding:chunked的话也没有存在Content-Length 的意义了。

那么问题来了，具体在应用的时候如何控制Tomcat响应的是Content-Length还是Tansfer-Encoding呢？