Cache-Control：must-revalidate, no-cache, private。
这个值告诉客户端，服务端不希望客户端缓存资源，在下次请求资源时，必须要从新请求服务器，不能从缓存副本中获取资源。
Cache-Control是响应头中很重要的信息，当客户端请求头中包含Cache-Control:max-age=0请求，明确表示不会缓存服务器资源时,Cache-Control作为作为回应信息，通常会返回no-cache，意思就是说，“不缓存就不缓存呗”；当客户端在请求头中没有包含Cache-Control时，服务端往往会定,不同的资源不同的缓存策略，比如说oschina在缓存图片资源的策略就是Cache-Control：max-age=86400,这个意思是，从当前时间开始，在86400秒的时间内，客户端可以直接从缓存副本中读取资源，而不需要向服务器请求。
Connection：keep-alive
这个字段作为回应客户端的Connection：keep-alive，告诉客户端服务器的tcp连接也是一个长连接，客户端可以继续使用这个tcp连接发送http请求。关于长连接的更多知识，后面我再详细讲。
Content-Encoding:gzip
告诉客户端，服务端发送的资源是采用gzip编码的，客户端看到这个信息后，应该采用gzip对资源进行解码。
Content-Type:text/html;charset=UTF-8
告诉客户端，资源文件的类型，还有字符编码，客户端通过utf-8对资源进行解码，然后对资源进行html解析。通常我们会看到有些网站是乱码的，往往就是服务器端没有返回正确的编码。
Content-type: text/html; charset=xxx的优先级要高于
<META http-equiv=”content-type” content=”text/html; charset=xxx”>
因为一个在headers中，一个在网页中。浏览器响应时，有时候是json文件，pdf文件等，这些文件里面没有设置编码，不像网页文件内部可以设置编码。所以headers中的>Content-type 优先级更高。
服务器可以设置响应文件的编码，其实功能相当于在 headers中设置 Content-type。如果headers已经有了Content-type，那就按服务器设置的方案，修改编码方式。
对于网页编码，headers中Content-type: text/html; charset=xxx；可以不用指定charset=xxx；因为网页内部也可以设置编码方案。
当时做了一个简易的web服务器，关键细节总结。
返回消息时，http 请求头和请求体 之间 需要 加 一个 【回车+换行】两个步骤。当然，java里面就一句 xxx.println();
当时，输出响应头时：
xxx.println(“Content-Type: text/css”); 这个css的类型，没有单独写。只是用if else 单独判断输出了 text/html text/javascript text/png image/jpeg image/gif ，其他的 一律输出 application/octet-stream 类型。所以一开始，请求 css 文件 时，响应头是 application/octet-stream 类型。然后，浏览器加载网页时，居然没有加载 css 文件。因为它认为 下载 的css文件，类型不对。所以网页渲染时，页面布局 混乱了。后来改成 输出 Content-Type: text/css 时，页面渲染成功了。
ETAG:字符串（出现在http1.1协议中，可选字段）
ETag在HTTP头字段中的使用是可选的（不像HTTP/1.1的其他头字段是强制性的）。HTTP规范从未指定生成ETag的方法。
ETag又叫实体标签（entity tag）是HTTP协议提供的若干机制中的一种Web缓存验证机制，并且允许客户端进行缓存协商。这就使得缓存变得更加高效，而且节省带宽。如果资源的内容没有发生改变，Web服务器就不需要发送一个完整的响应。ETag也可用于乐观并发控制，作为一种防止资源同步更新而相互覆盖的方法。
ETag是一个不透明的标识符，由Web服务器根据URL上的资源的特定版本而指定。如果那个URL上的资源内容改变，一个新的不一样的ETag就会被分配。用这种方法使用ETag即类似于指纹，并且他们能够被快速地被比较，以确定两个版本的资源是否相同。ETag的比较只对同一个URL有意义——不同URL上的资源的ETag值可能相同也可能不同，从他们的ETag的比较中无从推断。
Date：Sun, 21 Sep 2014 06:18:21 GMT
这个是服务端发送资源时的服务器时间，刚开始我不知道GMT是格林尼治所在地的标准时间，以为是服务器的时间错了，还去服务器上查看过时间。http协议中发送的时间都是GMT的，这主要是解决在互联网上，不同时区在相互请求资源的时候，时间混乱问题。
Expires:Sun, 1 Jan 2000 01:00:00 GMT
这个响应头也是跟缓存有关的，告诉客户端在这个时间前，可以直接访问缓存副本，很显然这个值会存在问题，因为客户端和服务器的时间不一定会都是相同的，如果时间不同就会导致问题。所以这个响应头是没有Cache-Control：max-age=***这个响应头准确的，因为max-age=date中的date是个相对时间，不仅更好理解，也更准确。
Pragma:no-cache
这个含义与Cache-Control等同。
Server：Tengine/1.4.6
这个是服务器和相对应的版本，只是告诉客户端服务器信息，没有更多的意思。
Transfer-Encoding：chunked
这个响应头告诉客户端，服务器发送的资源的方式是分块发送的。一般分块发送的资源都是服务器动态生成的，在发送时还不知道发送资源的大小，所以采用分块发送，每一块都是独立的，独立的块都能标示自己的长度，最后一块是0长度的，当客户端读到这个0长度的块时，就可以确定资源已经传输完了。
HTTP Header 之Content-Type介绍
Content-Type 实体头部用于指示资源的MIME类型 media type 。
在响应中，Content-Type标头告诉客户端实际返回的内容的内容类型。浏览器会在某些情况下进行MIME查找，并不一定遵循此标题的值; 为了防止这种行为，可以将标题 X-Content-Type-Options 设置为 nosniff。
在请求中 (如POST 或 PUT)，客户端告诉服务器实际发送的数据类型。
| Header type | Entity header |
|---|---|
| Forbidden header name | no |
| CORS-safelisted response-header | yes |
句法
Content-Type: text/html; charset=utf-8 Content-Type: multipart/form-data; boundary=something
指令
media-type- 资源或数据的 MIME type 。
- charset
- 字符编码标准。
- boundary
- 对于多部分实体，boundary 是必需的，其包括来自一组字符的1到70个字符，已知通过电子邮件网关是非常健壮的，而不是以空白结尾。它用于封装消息的多个部分的边界。
例子
Content-Type 在HTML表单中
在通过HTML form提交生成的POST请求中，请求头的Content-Type由<form>元素上的enctype属性指定
<form action="/" method="post" enctype="multipart/form-data"> <input type="text" name="description" value="some text"> <input type="file" name="myFile"> <button type="submit">Submit</button> </form>
请求头看起来像这样（在这里省略了一些 headers）：
POST /foo HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575
---------------------------974767299852498929531610575
Content-Disposition: form-data; name="description"
some text
---------------------------974767299852498929531610575
Content-Disposition: form-data; name="myFile"; filename="foo.txt"
Content-Type: text/plain
(content of the uploaded file foo.txt)
---------------------------974767299852498929531610575规范
| Specification | Title |
|---|---|
| RFC 7233, section 4.1: Content-Type in multipart | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |
| RFC 7231, section 3.1.1.5: Content-Type | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
参考：
https://my.oschina.net/manmao/blog/549123