初步解决过程和遗留问题

生产测试环境对比

content-length对比

目前的解决方案

指定客户端accept:application/json或者服务端返回的content-type:applcation/json

遗留的问题

为什么生产环境没有content-length而测试环境有？

为什么content-type不同content-length也会不同？为什么会乱码？

除了以下每个controller头指定produces,有没有统一的地方指定接口均返回的是application/json

@RestController

@RequestMapping(value = "/v1", produces = "application/json;charset=UTF-8")

public class XXXController

content-length

content-length 作用

Content-Length首部告诉浏览器报文中实体主体的大小。这个大小是包含了内容编码的.

使用Content-Length首部是为了能够检测出服务器崩溃而导致的报文截尾，并对共享持久连接的多个报文进行正确分段

http响应头里没有或者有content-length的几种可能性

1.客户端在http头(head)加Connection:keep-alive时，服务器的response是Transfer-Encoding:chunked的形式，通知页面数据是否接收完毕，例如长连接或者程序运行中可以动态的输出内容，例如一些运算比较复杂且需要用户及时的得到最新结果，那就采用chunked编码将内容分块输出。

2.除了如1所述之外的情况一般都是可以获取到Content-Length的。

在HTTP协议中，Content-Length用于描述HTTP消息实体的传输长度the transfer-length of the message-body。在HTTP协议中，消息实体长度和消息实体的传输长度是有_区别，比如说gzip压缩下，消息实体长度是压缩前的长度，消息实体的传输长度是gzip压缩后的长度。

如果head中有Content-Length，那么这个Content-Length既表示实体长度，又表示传输长度。如果实体长度和传输长度不相等(比如说设置了Transfer-Encoding)，那么则不能设置Content-Length。如果设置了Transfer-Encoding，那么Content-Length将被忽视”。这句话翻译的优点饶，其实关键就一点：有了Transfer-Encoding，则不能有Content-Length。

HTTP 协议中的 Transfer-Encoding

由于 Content-Length 字段必须真实反映实体长度，但实际应用中，有些时候实体长度并没那么好获得，例如实体来自于网络文件，或者由动态语言生成。这时候要想准确获取长度，只能开一个足够大的 buffer，等内容全部生成好再计算。但这样做一方面需要更大的内存开销，另一方面也会让客户端等更久。

我们在做 WEB 性能优化时，有一个重要的指标叫 TTFB(Time To First Byte)，它代表的是从客户端发出请求到收到响应的第一个字节所花费的时间。大部分浏览器自带的 Network 面板都可以看到这个指标，越短的 TTFB 意味着用户可以越早看到页面内容，体验越好。可想而知，服务端为了计算响应实体长度而缓存所有内容，跟更短的 TTFB 理念背道而驰。但在 HTTP 报文中，实体一定要在头部之后，顺序不能颠倒，为此我们需要一个新的机制：不依赖头部的长度信息，也能知道实体的边界。

杂谈Nginx与HTTP协议

在项目中遇到一个问题，需要详细了解下HTTP协议及其Nginx中对HTTP协议的支持程度。今天一天收集了一些资料，也梳理出最终方案。记录到博客上，方便后续查阅。重点关注以下几个方面：1、Http交互中如何判定内容的长度及其HTTP协议中关于Content-Length的解读。2、Chunk和Gzip在Nginx中的实现及原理。3、Upstream如何和Chunked结合。