来源：https://tools.ietf.org/html/rfc7231#section-5.3.4
例如：Accept-Encoding:gzip, deflate, sdch, br
一、Accept-Encoding：现实中，像邮局，将包裹如何，以及以哪一种方式打包。
表示浏览器可接受tomcat 传过来内容是如何编码的，是否是个gzip压缩格式，如java 文件里面的utf-8,Gb2312,unicode编码等等，有利于浏览器可以解析传过来的的文件。1.0 没有提供 q来选择优先级
The "Accept-Encoding" header field can be used by user agents to
indicate what response content-codings (Section 3.1.2.1) are
acceptable in the response. An "identity" token is used as a synonym
for "no encoding" in order to communicate when no encoding is
preferred.
Accept-Encoding = #( codings [ weight ] )
codings = content-coding / "identity" / "*"
Each codings value MAY be given an associated quality value
representing the preference for that encoding, as defined in
Section 5.3.1. The asterisk "*" symbol in an Accept-Encoding field
matches any available content-coding not explicitly listed in the
header field.
For example,
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
A request without an Accept-Encoding header field implies that the
user agent has no preferences regarding content-codings. Although
this allows the server to use any content-coding in a response, it
does not imply that the user agent will be able to correctly process
all encodings.
A server tests whether a content-coding for a given representation is
acceptable using these rules:
1. If no Accept-Encoding field is in the request, any content-coding
is considered acceptable by the user agent.
2. If the representation has no content-coding, then it is
acceptable by default unless specifically excluded by the
Accept-Encoding field stating either "identity;q=0" or "*;q=0"
without a more specific entry for "identity".
3. If the representation's content-coding is one of the
content-codings listed in the Accept-Encoding field, then it is
acceptable unless it is accompanied by a qvalue of 0. (As
defined in Section 5.3.1, a qvalue of 0 means "not acceptable".)
4. If multiple content-codings are acceptable, then the acceptable
content-coding with the highest non-zero qvalue is preferred.
An Accept-Encoding header field with a combined field-value that is
empty implies that the user agent does not want any content-coding in
response. If an Accept-Encoding header field is present in a request
and none of the available representations for the response have a
content-coding that is listed as acceptable, the origin server SHOULD
send a response without any content-coding.
Note: Most HTTP/1.0 applications do not recognize or obey qvalues
associated with content-codings. This means that qvalues might
not work and are not permitted with x-gzip or x-compress.i
二、Accept-Language：表示邮局的包裹要寄往那个国家，所在国家的交流语言。
表示客户浏览器优先使用什么语言交流
q:表示优先权
例如：Accept-Language:zh-CN,zh;q=0.8
Accept-Language = 1#( language-range [ weight ] )
language-range =
<language-range, see [RFC4647], Section 2.1>
Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and other types of English".
我更喜欢Danish,但是将将接受 British English 和其它类型的英文
三、Cache-Control :浏览器缓存控制
https://tools.ietf.org/html/rfc7234#section-5.2
例如：Cache-Control:max-age=0
Cache-Control = 1#cache-directive
cache-directive = token [ "=" ( token / quoted-string ) ]
For the cache directives defined below, no argument is defined (nor
allowed) unless stated otherwise.
1. max-age:tomcat的回应时间，如果超过浏览器指定的回应时间，浏览器不要。
表示从第一次浏览器向tomcat请求一个文件，设置这个文件回应时间，
到了tomcat 这边，tomcat 回应的浏览器一个文件，如果回应的时间大于这个文件请求时指定的时间，
那么就不接受tomcat送过来的文件。
=文件过期时间-第一次请求时间，单位秒
Argument syntax:
delta-seconds (see Section 1.2.1)
The "max-age" request directive indicates that the client is unwilling
to accept a response whose age is greater than the specified number of seconds.
The "max-age" 请求指令表示一个浏览器不愿意接受一个响应的文件，
这个响应文件的age是大于指定秒数
Unless the max-stale request directive is also present,
the client is not willing to accept a stale response.
This directive uses the token form of the argument syntax: e.g.,
'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the
quoted-string form.
2. max-stale
Argument syntax:
delta-seconds (see Section 1.2.1)
The "max-stale" request directive indicates that the client is
willing to accept a response that has exceeded its freshness
lifetime. If max-stale is assigned a value, then the client is
willing to accept a response that has exceeded its freshness lifetime
by no more than the specified number of seconds. If no value is
assigned to max-stale, then the client is willing to accept a stale
response of any age.
This directive uses the token form of the argument syntax: e.g.,
'max-stale=10' not 'max-stale="10"'. A sender SHOULD NOT generate
the quoted-string form.3. min-fresh
Argument syntax:
delta-seconds (see Section 1.2.1)
The "min-fresh" request directive indicates that the client is
willing to accept a response whose freshness lifetime is no less than
its current age plus the specified time in seconds. That is, the
client wants a response that will still be fresh for at least the
specified number of seconds.
This directive uses the token form of the argument syntax: e.g.,
'min-fresh=20' not 'min-fresh="20"'. A sender SHOULD NOT generate
the quoted-string form.
4. no-cache:每次请求直接发送给源服务器，而不经过本地缓存版本的校验
The "no-cache" request directive indicates that a cache MUST NOT use a stored response
to satisfy the request without successful validation on the origin server.
请求指令表示浏览器不必使用cache 存储一个响应，为了满足浏览器请求，不需要在浏览器验证成功，即浏览器缓
存版本校验。
5. no-store
The "no-store" request directive indicates that a cache MUST NOT
store any part of either this request or any response to it. This
directive applies to both private and shared caches. "MUST NOT
store" in this context means that the cache MUST NOT intentionally
store the information in non-volatile storage, and MUST make a
best-effort attempt to remove the information from volatile storage
as promptly as possible after forwarding it.
This directive is NOT a reliable or sufficient mechanism for ensuring
privacy. In particular, malicious or compromised caches might not
recognize or obey this directive, and communications networks might
be vulnerable to eavesdropping.
Note that if a request containing this directive is satisfied from a
cache, the no-store request directive does not apply to the already
stored response.6. no-transform
The "no-transform" request directive indicates that an intermediary
(whether or not it implements a cache) MUST NOT transform the
payload, as defined in Section 5.7.2 of [RFC7230].7. only-if-cached
The "only-if-cached" request directive indicates that the client only
wishes to obtain a stored response. If it receives this directive, a
cache SHOULD either respond using a stored response that is
consistent with the other constraints of the request, or respond with
a 504 (Gateway Timeout) status code. If a group of caches is being
operated as a unified system with good internal connectivity, a
member cache MAY forward such a request within that group of caches.