Request Headers 的其它 fields 值

来源：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.

 .  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.

  .  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.

  .  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.

   .  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 存储一个响应，为了满足浏览器请求，不需要在浏览器验证成功，即浏览器缓
存版本校验。

  .  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.

  .  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].

  .  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.