客户端（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呢？

我们都知道内置对象out，在调用print或者write的时候都会先往内部buffer里头写数据，而不是直接输出到客户端。Response Header 的 Content-Length 其实就是计算了buffer的数据长度。那他什么时候输出到客户端呢？有几种情况：

out的属性autoFlush为true，那么当buffer(默认大小是8 * 1024)的数据满了，Tomcat会自动向客户端flush一次数据，之后buffer就被重置了。必然Content-Length就拿不到了。所以这个时候Repsonse Header就成了Tansfer-Encoding:chunked。
out的属性autoFlush为false，如果数据超出了buffer的容量，这个时候会抛出异常IOException。
如果数据在buffer的容量范围之内，那么Content-Length可以被计算，头信息就会带上Content-Length。
如果手动调用了out.flush()，那么buffer中的数据立即会被输出到客户端，这个时候响应数据其实还未传输完毕，所以这种传输也可以看做分块传输了。Repsonse Header自然是Tansfer-Encoding:chunked。

zuul解决方案

添加 zuul.set-content-length=true