RFC2616-HTTP1.1-Header Field Definitions(头字段规定部分—译文)

part of Hypertext Transfer Protocol -- HTTP/1.1

RFC 2616 Fielding, et al.

14 头字段规定

　　该章节定义了HTTP1.1标准所包含的全部头字段的相关语法和含义。实体头字段是接收者或者发送者所涉及到的，并不区分是客户端仍是服务器所拥有，而是依据是谁发送或者是谁接受该实体的字段。

14.1 Accept

　　Accept请求头字段能够用来指定一个能被响应接受的肯定的媒体类型。Accept头字段能够用来标识那些在请求中特别指定类型的一个小范围的集合，好比请求内联图片的状况。

    　　   Accept         =  "Accept" ":" #( media-range(媒体范围) [ accept-params (可接受的参数)] )

   　　    media-range    = ( "*/*"  | ( type "/" "*" )   | ( type "/" subtype )   ) *( ";" parameter )

   　　    accept-params  = ";" "q" "=" qvalue *( accept-extension(可接受的扩展) )

   　　    accept-extension = ";" token(记号) [ "=" ( token | quoted-string(引用字符串) ) ]

　　星号"*"字符用来把媒体类型归类到ranges中，"*/*" 表示全部媒体类型均可以接受，"type/*"标明该媒体类型下的全部子类型。media-range能够包含适当范围内的媒体类型参数。

　　每一个media-range均可以跟随一个或多个accept-params参数，以q参数开始，用来代表相对的权重因子。第一个q参数（若是有的话）将media-range参数从accept-params字段中分隔开。权重参数容许用户或用户代理指示对该媒体范围的相对偏好程度，q的值在0到1范围内。默认的值是1。

　　请注意：使用“q”参数名称将媒体类型参数从Accept扩展参数中分离出来是有历史实践性的。尽管这可能会从媒体范围中阻止任何叫作“q”的媒体类型，可是因为IANA（因特网编号管理局）注册表中缺乏"q"字段的相关记录，而且Accept中不多使用任何媒体类型的参数，所以这种事情不太可能发生。

　　一个简单的例子：

     　　  Accept: audio/*; q=0.2, audio/basic

　　能够理解为我第一优先须要“audio/basic”格式，可是在下降百分之八十的标准后给我传送其余的audio类型也是能够的。

　　若是没有Accept投资段，那么假设客户端能够接受任何的媒体类型。若是存在Accept头字段，可是服务器没法发送一个包含Accept字段中可接受的响应，那么就会返回一个406状态码。

　　一个稍微复杂点的例子：

      　　 Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

　　口头上的解释是，首选的媒体类型是text/html和text/x-c，可是若是他们不存在，那么能够返回text/x-dvi实体，可是若是也不存在，那么就须要发送那个text/plain实体。

　　媒体范围（Media ranges）能够被更特定的媒体范围（Media ranges）或特定的媒体类型（media types）覆盖。若是一个给定类型应用了多个媒体范围，那么最特定的会被采用。咱们来看下面的例子：

    　　   Accept: text/*, text/html, text/html;level=1, */*

　　拥有如下的优先级

     　　  1) text/html;level=1

    　　   2) text/html

   　　    3) text/*

    　　   4) */*

　　与给定类型关联的媒体类型权重因子是经过找到与该类型匹配的具备最高优先级的媒体范围来肯定的。例如,

 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5

　　将会致使其关联的权重值是下面这样：

      　　 text/html;level=1    = 1

      　　 text/html                 = 0.7

     　　  text/plain                = 0.3

     　　  image/jpeg             = 0.5

     　　  text/html;level=2     = 0.4

    　　   text/html;level=3     = 0.7

　　注意:用户代理可能会为某些媒体范围提供一组默认的权重值。可是，除非用户代理是一个封闭的系统，不能与其余执行中的代理（rendering agents）交互，不然这个默认设置应该由用户配置。

14.2 Accept-Charset

　　Accept-Charset 请求头字段能够用来标示怎样的字符集能够在响应中使用。该字段容许客户端有能力去理解综合性更强或者具备特殊用途的字符集，具备向可以在这些字符集中表示文档的服务器发出信号的能力。

    　　  Accept-Charset = "Accept-Charset" ":" 1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )

　　在3.4小节咱们解释了有关于字符集的值的相关信息。每个字符能够拥有一个用来表示该字符权重的相关的值。权重的默认值是1。下面咱们看一个例子：

    　　  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

　　若是存在特殊的星号“*”在Accept-Charset字段中，匹配在Accept-Charset字段中没有说起的其余全部的字符集（包括ISO-8859-1）。若是该头字段中不存在星号，没有明确说起的全部字符集都得到权重值0，除了ISO-8859-1，若是没有明确说起，则得到权重值1。

　　若是没有Accept-Charset头字段，则说明任何字符都是能够接受的。若是存在该字段，可是服务器并无在响应中传递该字段容许的字符集，那么服务器须要返回一个406状态码，尽管传送一个不符合的响应也是被容许的。

14.3 Accept-Encoding

　　Accept-Encoding请求头字段与Accept头字段相似，可是限制了在响应用容许使用的内容编码（content-codeings，第3.5小节）。

     　　  Accept-Encoding  = "Accept-Encoding" ":"

                        　　  1#( codings [ ";" "q" "=" qvalue ] )

     　　  codings        = ( content-coding | "*" )

　　使用该字段的例子：

      　　 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

　　服务器根据Accept-Encoding字段测试内容编码（content-coding）是否能够接受，规则以下：

　　1.内容编码（content-coding）是不是在Accept-Encoding字段中列出的，若是是则能够接受，除非它伴有的权重值是0.（就像3.9小节所描述的，权重值为0则认为没法接受）

　　2.若是Accept-Encoding字段中存在特殊的星号“*”，那么意味着在任何在该字段中未明确说明的内容编码都是能够接受的。

　　3.若是有多个被容许的内容编码，那么权重值最高的优先。

　　4.身份（identity）内容编码老是能够被接受的，除非在Accept-Encoding字段中的identity字段的权重值是0,或者在字段中包含了“*；q=0”而且没有明确的“identity”内容编码。若是不存在Accept-Encoding，那么只有“identity”是被容许的。

　　若是一个请求中存在Accept-Encoding字段，可是服务器没法提供该字段范围内的响应，那么服务器须要返回一个406错误响应。

　　若是请求中没有Accept-Encoding头字段，那么服务器则假设客户端能够接受任何类型编码的内容。在这种状况下，若是“identity”是被容许的内容编码之一，那么服务器须要使用“identity”内容编码，除非有额外的信息代表其余的内容编码对客户端更有意义。

　　注意:若是请求不包含Accept-Encoding字段，若是"identity"内容编码不可用，那么HTTP/1.0客户端会使用通用的content-codings(即，“gzip”和“compress”);一些较老的客户端可能会不正确地显示与其余内容编码一块儿发送的消息。服务器还能够根据特定用户代理或客户端的信息作出此决定。

　　注意:大多数HTTP/1.0应用程序不识别或不遵照与内容编码相关的qvalue。这意味着qvalues将不能工做，x-gzip或x-compress中不容许使用qvalues。

14.4 Accept-Language

　　该字段也Tm跟Accept字段相似，可是它限制了请求中须要的天然语言集合的首选范围。语言标识符在3.10小节中已经详细说明。

      　　 Accept-Language = "Accept-Language" ":" 1#( language-range [ ";" "q" "=" qvalue ] )

       　　language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

　　每个语言范围（language-range）能够拥有一个表示预计用户在该语言范围内更倾向的语言的相关联的权重值。默认的权重值是1。好比：

       　　Accept-Language: da, en-gb;q=0.8, en;q=0.7

　　意味着：“我须要丹麦语（Danish），可是英式英语或者其余类型的英语也是能够接受的”。若是语言范围正好等于标记，或者正好等于标记的前缀，则语言范围匹配语言标记，使得前缀后面的第一个标记字符是“-”。若是在Accept-Language字段中存在特殊范围“*”，则与Accept-Language字段中存在的任何其余范围不匹配的每一个标记匹配。

　　注意：前缀匹配规则的这种使用并不意味着语言标签是以这样的方式分配给语言的，即若是用户理解具备特定标记的语言，那么该用户也将理解具备该标记为前缀的全部标记的语言。若是是这样的话，前缀规则只容许使用前缀标签。

　  Accept-Language字段分配给语言标签的权重因子是与语言标签匹配的字段中最长的语言范围的权重值。若是字段中没有语言范围与标签匹配，则分配的语言权重值为0。若是请求中不存在Accept-Language字段头，则服务器应假定全部语言都一样可接受。若是存在Accept-Language字段头，则分配大于0的权重值的全部语言都是可接受的。

　　在每次请求中发送带有用户完整语言首选项的Accept-Language报头可能与用户的隐私指望相反。有关这个问题的讨论，请参阅第15.1.4节。

　　因为可理解性高度依赖于单个用户，所以建议客户端应用程序容许用户能够选择语言首选项。若是选择不可用，则不能在请求中给出 Accept-Language头字段。

　　注意：当用户可以选择语言偏好时，咱们但愿提醒开发者，用户并不熟悉上述语言匹配的细节，而且应该提供适当的指导。举个例子，用户可能会假设在选择“en-gb”时，若是英式英语不可用，他们会获得任何类型的英语文档。在这种状况下，用户代理可能会建议使用“EN”以得到最佳匹配行为。

14.5 Accept-Ranges

　　Accept-Ranges响应头字段容许服务器代表其所接受资源的范围：

          Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges

          acceptable-ranges = 1#range-unit | "none"

　　接受字节范围（byte-range）请求的源服务器能够发送

          Accept-Ranges: bytes

　　可是咱们并不须要这样作。客户端能够生成字节范围（byte-range）请求，而不为所涉及的资源接收此报头。范围单元（Range units）在3.12小节中作了说明。

　　若是发送了以下的字段，那么服务器不会接受任何范围的请求。

          Accept-Ranges: none

　　建议客户端不要尝试范围请求。

14.6 Age

　　Age响应头字段传递发送方对该响应（或从新验证）在原始服务器上生成以来的时间的大体估计，若是缓存的响应的生命周期不超过新鲜度（fresh），那么它就是最新的。在13.2.3小节中指定了如何去计算Age的值。

           Age = "Age" ":" age-value

           age-value = delta-seconds

　　Age的值是非负的十进制整数，表示时间（以秒为单位）。若是一个缓存接收到一个大于它所能表示的最大正整数的值，或者Age计算出的值溢出，那么它必须发送一个值为2147483648（2^31）的Age头字段。包含缓存的HTTP/1.1服务器必须在其自身缓存生成的每一个响应中包含Age头字段。缓存应该使用至少31位的算术类型。

14.7 Allow

　　Allow实体头字段列出了由请求URI（Request-URI）所标识的资源所支持的一组方法。此字段的目的是严格的告知接收方与该资源关联的有效方法。Allow字段必须在405（Method Not Allowed）响应中存在。

          Allow   = "Allow" ":" #Method

　　使用例子：

          Allow: GET, HEAD, PUT

　　该字段没法阻止客户端尝试其余方法。

　　可是，咱们应该遵循Allow头字段的值所给出的指示。被容许使用的方法的实际集合会在每一次请求的元服务器中明确的指定。

 　　Allow头字段能够提供一个PUT方法以使用户提早知道一个新资源或者一个被修改的资源当前所支持的方法。服务器无需支持这些方法，可是须要在响应中包含一个Allow头字段告知用户该资源实际支持的方法有哪些。

　　一个代理不能修改Allow头字段中的内容既是它彻底没法理解全部方法所具备的特性，由于可能咱们的客户端在与服务器交流的时候有其余的用意。

14.8 Authorization

　　用户代理但愿经过服务器(一般是在收到401响应以后，但不必定是在收到401响应以后)进行身份验证，验证的方法是在请求中包含一个Authorization请求头字段。Authorization字段值由凭证（credentials）组成，凭证包含所请求资源范围的用户代理的身份验证信息。

       　　Authorization  = "Authorization" ":" credentials

　　 该（"HTTP Authentication:Basic and Digest Access Authentication"）文章介绍了HTTP如何访问身份验证信息。若是某个请求经过了身份验证并指定了一个域，那么该域内的全部其余请求应该具备相同的凭证（假设身份验证方案自己不须要其余凭证，例如根据质询值变化的凭证或使用同步时钟）。

　　当共享缓存（参见第13.7节）接收到包含Authorization字段的请求时，它不能返回相应的响应做为对任何其余请求的回复，除非存在如下特定状况之一：

　　1.若是一个响应包含了“s-maxage”缓存控制（Cache-Control）指令，该缓存可使用该响应回复以后的请求。可是（若是已经超过最大的指按期限）代理缓存必须优先与服务器进行验证，使用新请求的请求头来容许源服务器验证新请求。（这是s-maxage的定义行为。）若是响应包括“s-maxage=0”，则代理必须老是在从新使用以前对其进行从新验证。

　　2.若是响应中包含“must-revalidate”缓存控制指令（ cache-control directive），缓存能够在答复后续请求时使用该响应。可是，若是响应已通过期，全部缓存必须首先用源服务器从新验证它，使用来自新请求的请求头来容许源服务器验证新请求。

　　3.若是响应包含“public”缓存控制指令，则能够回复任何后续请求。

14.9 Cache-Control

　　Cache-Control通用头字段用于指定在请求/响应链上全部的缓存都必须遵照的规则。指令的指定旨在防止缓存对请求或响应产生不利干扰的一些行为。这些指令一般会重写默认缓存算法。缓存指令是单项的，请求中存在指令并不意味着响应中也将会给出相同的指令。

　　注意：HTTP/1.0协议版本下的缓存可能没法实现缓存控制，只能实现Pragma(编译指示): no-cache (详情请见 14.32小节).

　　缓存指令必须由代理或网关应用程序传递，不管这些指令对该程序是否有用，由于这些指令可能适用于请求/响应链上的全部接收者。咱们不可能为特定的缓存指定缓存指令。

    　　Cache-Control   = "Cache-Control" ":" 1#cache-directive

   　　 cache-directive = cache-request-directive | cache-response-directive

    　　cache-request-directive =

          　　 "no-cache"                          ; Section 14.9.1

        　　 | "no-store"                          ; Section 14.9.2

        　　 | "max-age" "=" delta-seconds         ; Section 14.9.3, 14.9.4

         　　| "max-stale" [ "=" delta-seconds ]   ; Section 14.9.3

         　　| "min-fresh" "=" delta-seconds       ; Section 14.9.3

         　　| "no-transform"                      ; Section 14.9.5

         　　| "only-if-cached"                    ; Section 14.9.4

        　　 | cache-extension                     ; Section 14.9.6

     　　cache-response-directive =

         　　"public"                               ; Section 14.9.1

                | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1

         　　| "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1

       　　  | "no-store"                             ; Section 14.9.2

         　　| "no-transform"                         ; Section 14.9.5

         　　| "must-revalidate"                      ; Section 14.9.4

        　　 | "proxy-revalidate"                     ; Section 14.9.4

        　　 | "max-age" "=" delta-seconds            ; Section 14.9.3

        　　 | "s-maxage" "=" delta-seconds           ; Section 14.9.3

       　　 | cache-extension                        ; Section 14.9.6

    cache-extension = token [ "=" ( token | quoted-string ) ]

　　当指令没有任何一个字段名参数出现时，该指令适用于整个请求或响应。当这样的指令以符合要求的字段名参数出现时，它只适用于命名字段，而不适用于请求或响应的其他部分。该机制支持可扩展性；HTTP协议的将来版本的实现可能将这些指令应用于HTTP/1.1中未定义的头字段。

　　缓存控制指令能够分解为如下这些通常类别。

　　　　-限制什么是可缓存的；这些只能由源服务器强加。

　　　　-对缓存能够存储的内容的限制；这些能够由源服务器或用户代理强制执行。

　　　　-基本过时机制的修改；这些能够由源服务器或用户代理强制执行。

　　　　-对缓存从新验证和从新加载进行控制；这些可能仅由用户代理强制执行。

　　　　-控制实体的转换。

　　　　-缓存系统的扩展。

14.9.1 What is Cacheable

　　默认状况下，若是请求方法、请求头字段和响应状态的指示该响应是可缓存的，则响应是可缓存的。第13.4小节总结了这些可缓存性的默认值。下面的Cache-Control响应指令容许源服务器重写响应的默认缓存性：

public

　　指示响应可能由任何缓存来缓存资源，即便它一般不可缓存或仅在非共享缓存中缓存。（请参阅受权，第14.8小节，以了解更多细节。）

private

　　指示响应消息的所有或部分用于单个用户，而不能由共享缓存缓存。这容许源服务器声明响应的指定部分仅针对一个用户，而不能对其余用户的请求进行有效响应。私有（非共享）缓存能够缓存响应。

　　注意： private一词的在这里的语义只是控制响应能够缓存在哪里，并不能确保消息内容的隐私性。

no-cache

　　若是无缓存（no-cache）指令没有指定字段名，则缓存不能使用该响应来知足后续请求，而无需与原始服务器从新验证成功。这容许源服务器甚至经过配置成向客户端请求返回过时响应的缓存来防止缓存。

　　若是非缓存指令确实指定了一个或多个字段名，则缓存可使用响应来知足后续请求，但受缓存上的任何其余限制。可是，在没有与原始服务器成功从新验证的状况下，在响应后续请求时，必须不发送指定的字段名。这容许源服务器防止在响应中重用某些头部字段，同时仍然容许缓存响应的其他部分。

　　注意：大部分HTTP/1.0协议下的缓存没法识别或遵照该指令

14.9.2 What May be Stored by Caches

no-store

　　no-store指令存在的目的是阻止那些无心间发布或保留的敏感信息（例如，备份信息）。no-store指令为整个消息提供实用，可能会被响应或请求发送。若是在请求中发送，缓存必定不能被请求的任何部分或响应该请求的响应存储。若是在响应中发送，则缓存不能存储该响应的任何部分或引起该请求的请求。该指令也适用于非共享和共享缓存。“必须不存储”在此上下文中意味着缓存必须不故意将信息存储在非易失性存储器中，而且必须尽力在转发信息以后尽量迅速地从易失性存储器中删除信息。

　　即便这个指令与响应相关联，用户也能够在缓存系统以外显式地存储这样的响应（例如，使用“另存为”对话框）。历史缓冲区能够存储这些响应做为正常操做的一部分。

　　本指令的目的是知足某些用户和服务做者的既定要求，这些用户和服务做者担忧经过意外访问缓存数据结构而泄漏信息。虽然在某些状况下，使用本指令可能改善一些隐私的保密性，但咱们警告说，它毫不是确保隐私的可靠或充分的机制。特别地，恶意或受损的缓存可能没法识别或听从这个指令，而且在这种状况下，通讯网络可能很容易被窃听。

14.9.3 Modifications of the Basic Expiration Mechanism

　　源服务器可使用Expires头字段指定实体的过时时间(参见14.21节)。或者，能够在响应中使用max-age指令指定它。当缓存的响应中出现max-age cache-control指令时，若是当前时间大于对该资源的新请求时给出的时间值(以秒为单位)，则响应就失效了。响应的max-age指令意味着响应是可缓存的(即，“public”）除非有其余更严格的缓存指令。

　　若是一个响应同时包含一个Expires头字段和一个max-age指令，则max-age指令将覆盖Expires头字段，即便Expires头字段有更多的限制。该规则容许源服务器为给定的响应提供比HTTP/1.0缓存更长(或更高)的HTTP/1.1缓存过时时间。若是某些HTTP/1.0缓存没法正确地计算时间或过时时间，这多是有用的，致使该状况的缘由多是因为时钟不一样步。

　　许多HTTP/1.0缓存实现会将一个小于或等于响应日期值的Expires值视为等同于cache - control的“no-cache”响应指令。若是HTTP/1.1缓存接收到这样的响应，而且响应不包含cache - control头字段，则应该认为响应不可缓存，以保持与HTTP/1.0服务器的兼容性。

　　 注意:源服务器可能但愿在网络上使用相对较新的HTTP缓存控制特性，好比“private”指令，其中包括不理解该特性的旧缓存。原始服务器须要将新特性与一个Expires字段合并，该字段的值小于或等于日期值。这将防止旧的缓存不正确地缓存响应。

s-maxage

　　若是响应包含一个s-maxage指令，那么对于共享缓存(但不是私有缓存)，该指令指定的最大使用时限将覆盖由max-age指令或Expires头指定的最大使用时限。s-maxage指令还包含代理从新验证指令的语义(参见14.9.4节)，即，在实体过时后，缓存在原始服务器没有从新验证它以前必须不能使用该实体来响应后续请求。私有缓存老是忽略s-maxage指令。

　　注意，大多数旧的缓存行为，不遵循这个规范，没法实现任何缓存控制指令。若是源服务器但愿使用该限制规范但又不防止HTTP/1.1兼容缓存的cache-control指令，那么它可能会利用max-age指令覆盖Expires头字段的要求，以及HTTP/1.1以前的版本兼容的缓存不遵照max-age指令的事实。

　　其余指令容许用户代理修改基本的过时机制。这些指示可按要求指定:

max-age

　　指示客户端愿意接受时限不大于指定时间(以秒为单位)的响应。除非还包含了旧的指令，不然客户端不但愿接受旧的响应。

min-fresh

　　表示客户端愿意接受新鲜度时限不小于当前时间加上指定时间(以秒为单位)的响应。也就是说，客户端但愿响应至少在指定的秒数内仍然是有效的。

max-stale

　　指示客户端愿意接受超过过时时间的响应。若是赋给max-stale值，那么客户端愿意接受超过其过时时间不超过指定秒数的响应。若是没有赋值给max-stale赋值，那么客户愿意接受任什么时候限的陈旧响应。

　　若是缓存返回陈旧的响应，或者由于请求上的max-stale指令，或者由于缓存被配置为覆盖响应的过时时间，那么缓存必须使用警告110(响应过期了)并将警告标头附加到过期的响应上。

　　缓存能够配置为在不进行验证的状况下返回过期的响应，但前提是这与缓存验证的任何“必须”级别需求(例如，“必须从新验证”cache-control指令)不冲突。

　　若是新请求和缓存内容都包含“max-age”指令，那么两个值中的较小值将用于肯定该请求缓存内容的新鲜度。

14.9.4 Cache Revalidation and Reload Controls

　　有时候，用户代理可能但愿或须要坚持让缓存使用原始服务器从新验证其缓存条目(而不只仅是使用沿着原始服务器路径的下一个缓存)，或者从原始服务器从新加载其缓存条目。若是缓存或原始服务器高估了缓存响应的过时时间，那么端到端从新验证多是必要的。若是缓存条目因为某种缘由损坏，那么端到端的从新加载多是必要的。

　　端到端从新验证能够在客户端没有本身的本地缓存副本时请求，在这种状况下，咱们将其称为“未指定的端到端从新验证”，或者当客户端有本地缓存副本时，在这种状况下，咱们将其称为“特定的端到端从新验证”。

　　客户端可使用Cache-Control请求指令指定这三种操做:

End-to-end reload（端到端从新加载）

　　这个请求包括一个“无缓存（no-cache）”cache-control指令，或者为了与HTTP/1.0客户端兼容，使用“Pragma: no-cache”。在请求中，字段名不能包含在无缓存指令中。服务器在响应此类请求时不能使用缓存副本。

Specific end-to-end revalidation（特定的端到端从新生效）

　　该请求包括一个“max-age=0”cache-control指令，该指令强制沿着到原始服务器的路径中的每一个缓存与下一个缓存或服务器一块儿从新验证本身的条目(若是有的话)。最初的请求包括一个缓存验证条件和客户端的当前验证器。

Unspecified end-to-end revalidation（未指定的端到端再校验）

　　该请求包括“max-age=0”缓存控制指令，该指令强制沿着到源服务器的路径的每一个缓存使用下一个缓存或服务器从新验证其本身的条目（若是有的话）。初始请求不包括缓存验证条件，沿着保存该资源的缓存条目的路径（若是有的话）的具备其当前验证器的缓存验证条件的第一个缓存。

max-age

　　当经过max-age=0指令强制中间缓存从新验证其本身的缓存条目，而且客户端在请求中提供了本身的验证器时，所提供的验证器可能与当前存储在缓存条目中的验证器不一样。在这种状况下，缓存可使用验证器来进行本身的请求，而不影响语义透明性。

　　可是，验证器的选择可能会影响性能。最好的方法是中间缓存使用它本身的验证器来进行请求。若是服务器用304（Not Modified.）进行响应，则缓存能够向客户端返回其如今已验证的副本，并带有200（OK）响应。可是，若是服务器用新的实体和缓存验证器进行响应，则中间缓存可使用强比较函数将返回的验证器与客户端请求中提供的验证器进行比较。若是客户端的验证器等于源服务器，则中间缓存只返回304（Not Modified.）。不然，它返回具备200（OK）响应的新实体。

　　若是请求包含no-cache指令，则不该包括min-fresh、max-stale或max-age。

only-if-cached

　　在某些状况下，好比网络链接性很是差的时候，客户端可能但愿缓存只返回它当前存储的响应，而不是使用原始服务器从新加载或从新验证。要作到这一点，客户端能够在请求中包含noly-if-cached指令。若是它接收到这个指令，缓存应该使用与请求的其余约束一致的缓存条目进行响应，或者使用504(网关超时-Gateway Timeout)状态进行响应。可是，若是一组缓存做为一个统一的系统进行操做，而且具备良好的内部链接，则该请求能够在该组缓存中转发。

must-revalidate（必须从新验证）

　　由于缓存可能忽略服务器配置的指定过时时间,由于客户端请求可能包括max-stale指令(也有相似的效果),该协议还包括一个源服务器的机制须要从新验证缓存条目的任何后续使用。当必须从新验证指令出如今缓存接收到的响应中时，该缓存必须在条目过时后使用该条目来响应后续请求，而不优先使用原始服务器从新验证该条目。(即。若是仅基于原始服务器的Expires或max-age值，缓存的响应就过期了，那么每次缓存都必须执行端到端从新验证。）

　　must-revalidate指令对于支持某些协议特性的可靠操做是必要的。在任何状况下，HTTP/1.1缓存必须遵照“must-revalidate”指令;特别是，若是缓存因为任何缘由没法到达原始服务器，它必须生成504(网关超时)响应。

　　服务器应该发送“must-revalidate”指令，当且仅当在实体上从新验证请求失败可能致使错误操做(如未执行的财务事务)时才发送该指令。接收方不得采起任何违反此指令的自动操做，也不得在从新验证失败时自动提供实体的未验证副本。

　　尽管不建议这样作，可是在严格的链接约束下操做的用户代理可能违反此指令，但若是是这样，则必须明确警告用户已经提供了未经验证的响应。每一个未经验证的访问都必须提供警告，而且须要明确的用户确认。

proxy-revalidate（代理从新验证）

　　proxy-reavalidate指令的含义与must-revalidate指令相同，只是它不适用于非共享的用户代理缓存。提供每次从新验证的服务(为了确保每一个用户已经经过身份验证)。

它可使用在回应一个身份验证请求,容许用户的缓存来存储和后来返回响应,而不须要从新验证(由于它已经被该用户身份验证一次),同时还要求代理服务许多用户从新验证每一次(为了确保每一个用户已经经过身份验证)。注意，这种通过身份验证的响应还须要“public”缓存控制指令，以便可以彻底缓存它们。

14.9.5 No-Transform Directive

no-transform

　　中间缓存（代理）的实现者发现转换某些实体的媒体类型是有用的。例如，非透明代理能够在图像格式之间进行转换，以便节省缓存空间或减小慢速链路上的通讯量。

　　然而，当这些转换应用于特定类型的应用程序实体时，会出现严重的操做问题。例如，用于医学成像、科学数据分析以及使用端到端认证的应用都依赖于接收与原始实体-主体逐位相同（bit for bit identical——也就是每一字节都与原实体同样）的实体主体。

　　所以，若是消息包括no-transform指令，则中间缓存或代理必须不改变那些在第13.5.2节中列出的、受no-transform指令制约的报头。这意味着缓存或代理必须不改变由这些头字段指定的实体主体的任何方面，包括实体主体自己的值。　　

14.9.6 Cache Control Extensions

　　能够经过使用一个或多个缓存扩展令牌来扩展Cache-Control头字段，每一个令牌具备可选的分配值。能够在不改变其余指令的语义的状况下添加信息扩展（不须要改变缓存行为的扩展）。行为扩展被设计为经过对缓存指令的现有基础做为修饰符来工做。提供新的指令和标准指令，使得不理解新指令的应用程序将默认执行标准指令指定的行为，而理解新指令的应用程序将认识到它修改了与标准指令相关的需求。这样，能够在不修改基础协议的状况下，对缓存控制指令进行扩展。

　　这种扩展机制依赖于HTTP缓存，它遵照为其原生HTTP版本定义的全部缓存控制指令，遵照某些扩展，并忽略它不理解的全部指令。

　　例如，假设有一个名为community的新响应指令，它充当私有指令的修饰符。咱们定义这个新指令是为了表示，除了任何非共享缓存以外，任何仅由值中指定的社区成员共享的缓存均可以缓存响应。但愿容许UCI社区在其共享缓存中使用私有响应的源服务器能够经过包括下面的字段来实现这一点

       Cache-Control: private, community="UCI"

　　即便缓存不理解community cache-extension，看到这个header字段的缓存也会正常工做，由于它也会看到并理解私有指令，所以默认为安全行为。

　　不能识别的缓存指令必须被忽略;假设任何缓存指令可能没法被HTTP/1.1缓存识别，将与标准指令结合使用(或者响应的默认缓存能力，即便缓存不理解扩展，缓存行为也将保持最低限度的正确性)。

14.10 Connection

　　Connection通用头字段容许发送方指定特定连接所需的选项，而且代理不能经过其余连接进行通讯。

　　Connection头字段的语法以下：

      　　 Connection = "Connection" ":" 1#(connection-token)

       　　connection-token  = token

　　在Connection字段中列出的Message头字段不能包含端到端类型的头字段，好比Cache-Control。　　

　　HTTP/1.1为发送方定义了“close”链接选项，以表示链接将在响应完成后关闭。好比：

       　　Connection: close

　　不管在响应仍是请求中都表示在响应或请求完成后，该连接不能被看成持久连接。

　　不支持持久连接的HTTP／1.1应用程序必须在每个消息（message）中包含close连接选项。

　　接收包含Connection头字段的HTTP/1.0(或较低版本)消息的系统，对于该字段中的每一个链接令牌（coonection-token），必须从与链接令牌同名的消息中删除和忽略任何头字段。这能够防止这些头字段被http /1.1代理错误转发。（详情见19.6.2小节）

14.11 Content-Encoding

　　Content-Encoding实体头字段被用来看成media-type的调节器。当存在时，它的值指示哪些附加的内容编码已经应用到实体主体，所以咱们要知道在Content-Type头字段中使用的media-type须要使用怎么样的解码机制。Content-Type主要用于容许文档被压缩而不丢失其底层媒体类型的特征。

       Content-Encoding  = "Content-Encoding" ":" 1#content-coding

　　内容编码在 3.5中被定义。一个使用的例子：

       Content-Encoding: gzip

　　内容编码是由请求URI标识的实体的特性。典型地，实体用这样的编码方式存储，而且只有在渲染内容或相似的状况下使用以前才被解码。然而，除非消息中存在“no-transform”缓存控制指令，不然，若是已知接收方能够接受新编码，则非透明代理能够修改内容编码。

　　若是一个实体的内容编码不是“identity”，而后，响应必须包含内容编码实体头(14.11节)，其中列出了使用的非标识内容编码。

　　若是原始服务器没法接受请求消息中实体的内容编码，则服务器应以状态码415(Unsupported Media Type)进行响应。

　　若是多个编码被应用到一个实体中，内容编码必须按照应用它们的顺序列出。有关编码参数的其余信息能够由本规范未定义的其余实体头字段提供。

14.12 Content-Language

　　Content-Language 实体头字段描述了封闭实体的预期受众的天然语言。注意，这可能不等于实体主体（entity-body）中使用的全部语言。

       　　Content-Language  = "Content-Language" ":" 1#language-tag

　　语言标识在 3.10节中作了定义。内容语言的主要目的是容许用户根据本身的首选语言识别和区分实体。所以，若是正文内容仅针对具备丹麦语文化的读者，则适当的范围是

      　　 Content-Language: da

　　若是没有指定内容语言，默认状况下内容是针对全部语言受众的。这可能意味着发送方不认为它是特定于任何天然语言的，或者发送方不知道它是针对哪一种语言的。

　　能够为多个受众列出多个语言的内容。例如，同时在原始毛利语和英语版本中出现的《瓦伊坦吉条约》的译本就须要

      　　 Content-Language: mi, en

　　然而，仅仅由于多个语言存在于一个实体中并不意味着它是针对多个语言受众的。举个例子，初学者的语言入门，好比“拉丁语第一课”，很明显是用来让有英语基础的观众使用的。在这种状况下，内容语言将只包括“EN”。

　　Content-Language能够应用于任何媒体类型——它不限于文本文档。

14.13 Content-Length

　　Content-Length实体头字段表示实体内容的大小，发送给接收者的是一个十进制八位字节的数字，在HEAD方法中，若是请求是GET，那么将发送的实体主体的大小。

       　　Content-Length    = "Content-Length" ":" 1*DIGIT

　　下面是一个例子

       　　Content-Length: 3495

　　应用程序应该使用此字段来指示消息体的传输长度（transfer-length），除非第4.4节中的规则禁止这一点。

　　任何大于或等于0的内容长度都是一个有效值。第4.4节描述了若是没有提供内容长度，如何肯定消息体的长度。

　　注意，这个字段的含义与MIME中相应的定义有很大的不一样，MIME是“消息/外部体”（"message/external-body"）内容类型中使用的可选字段。在HTTP中，只要消息的长度能够在传输以前肯定，就应该发送它，除非第4.4节中的规则禁止这一点。

14.14 Content-Location

　　当从与请求资源的URI分离的位置访问该实体时，可使用Content-Location实体头字段为消息中包含的实体提供资源位置。服务器应该为响应实体对应的变体提供内容位置;特别是当一个资源有多个与它相关联的实体，而且这些实体实际上有单独的位置，经过这些位置能够单独访问它们，服务器应该为返回的特定变体提供一个内容位置。

      　　Content-Location = "Content-Location" ":"( absoluteURI | relativeURI )

　　Content-Location的值也定义了基本实体的URI。

　　Content-Location的值不是原始请求URI的代替;它只是请求时对应于此特定实体的资源位置的声明。若是但愿标识特定实体的源，未来的请求能够指定Content-Location URI做为请求URI。

　　缓存不能假设具备与用于检索它的URI不一样的内容位置的实体能够用于响应该内容位置URI上的稍后请求。然而，Content-Location可用于区分从单个请求资源检索的多个实体，如第13.6节所述。

　　若是Content-Location是一个相对的URI标识，相对URI是相对于请求URI解释的。

　　在PUT或Post请求中Content-Location头字段是未定意的。服务器在这种状况下会忽略这些内容。

14.15 Content-MD5

　　RFC 1864中定义的Content-MD5实体头字段是实体主体的MD5摘要，用于提供实体主体的端到端消息完整性检查（MIC）。（注意：MIC用于检测传输中的实体主体的意外修改，但不能防止恶意攻击。）

        　　Content-MD5   = "Content-MD5" ":" md5-digest

        　　md5-digest   = <base64 of 128 bit MD5 digest as per RFC 1864>

　　Content-MD5头字段能够由源服务器或客户端生成，以做为实体主体的完整性检查。只有原始服务器或客户端可能生成Content-MD5头字段；代理和网关不能生成，由于这将破坏其做为端到端完整性检查的价值。任何实体主体的接收者，包括网关和代理，均可以检查这个头字段中的摘要值是否与接收到的实体主体的摘要值匹配。

　　MD5摘要是基于实体主体的内容计算的，包括已经应用的任何内容编码，但不包括应用到消息主体的任何传输编码。若是用传输编码接收到消息，则必须在根据接收到的实体检查Content-MD5值以前删除该编码。

　　这样作的结果是，在实体主体的八位字节上精确地计算摘要，而且若是没有应用传输编码，则按照这样的顺序发送摘要。

　　HTTP扩展了RFC 1864，容许为MIME复合媒体类型（例如，multipart/*和message/rfc822）计算摘要，但这并不改变如前段所定义的摘要的计算方式。

　　这有几个后果。复合类型的实体主体可能包含许多主体部分，每一个部分都有本身的MIME和HTTP头(包括Content-MD五、Content-Transfer-Encoding和Content-Encoding头)。若是body-part具备content - transfer - encoding头字段，则假设body-part的内容已经应用了编码，而且body-part包含在content - md5摘要中，以下所示:以后的运行中。在主体部分中不容许使用Transfer-Encoding头字段。

　　在计算或检查摘要以前，不能将全部换行符转换为CRLF:实际传输的文本中使用的换行约定在计算摘要时必须保持不变。

　　注意：尽管Content-MD5的定义对于HTTP与RFC 1864对于MIME实体主体的定义彻底相同，可是在几种状况下，Content-MD5对于HTTP实体主体的应用不一样于其对于MIME实体主体的应用。一种是HTTP不一样于MIME，它不使用内容传输编码，但使用传输编码和内容编码。另外一个缘由是HTTP比MIME更频繁地使用二进制内容类型，所以值得注意的是，在这种状况下，用于计算摘要的字节顺序是为该类型定义的传输字节顺序。最后，HTTP容许使用几种换行规则中的任何一种来传输文本类型，而不只仅是使用CRLF的规范形式。

14.16 Content-Range

　　Content-Range实体头字段与部分实体主体一块儿发送，以指定在完整实体主体中应该在何处应用部分主体。范围单元在3.12节中定义。

      　　 Content-Range = "Content-Range" ":" content-range-spec

       　　content-range-spec          =  byte-content-range-spec

      　　 byte-content-range-spec  =  bytes-unit SP

                                　　　　　 　　 byte-range-resp-spec "/"  ( instance-length | "*" )

      　　 byte-range-resp-spec   　= (first-byte-pos "-" last-byte-pos)  | "*"

    　　   instance-length                = 1*DIGIT

　　报头应该指示完整实体的总长度，除非这个长度是未知的或难以肯定的。星号“*”字符表示在生成响应时，实例长度未知。

　　与byte-ranges-specifier的值（参见14.35.1节）不一样，byte-range-resp-spec必须只指定一个范围，而且必须包含该范围的第一个和最后一个字节的绝对字节位置。

　　当一个byte-range-resp-spec存在一个byte-content-range-spec值，而且该值的最后一位（last-byte-pos）小于它的第一位（first-byte-po），或者它的实际长度（instance-length）小于或等于它最后一位（last-byte-pos），这样是不容许的。接收者应该忽略一个未经过验证的byte-content-range-spec，以及随其传输的任何其余内容。

　　发送具备状态代码416（请求范围不可知足）的响应的服务器应该包括具备byte-range-resp-spec的值为“*”的Content-Range字段。实例长度指定所选资源的当前长度。使用状态代码206（部份内容）的响应不能包含具备“*”字节的 byte-range- resp-spec字段。　　

　　下面是一个字节内容范围规则值(byte-content-range-spec)的例子，假设实体总共包含了1234字节：

      　　. 最开始的500个字节: bytes 0-499/1234

     　　 . 第二个五百个字节: bytes 500-999/1234

    　　  . 除了前五百个字节: bytes 500-1233/1234

      　　. 最后五百个字节： bytes 734-1233/1234

　　当一个HTTP消息包含一个单一范围的内容(例如,一个响应请求一个单一的范围,或者请求一组没有任何漏洞的重叠范围),该内容与Content-Range头字段一块儿传递,而且Content-Length头字段应该显示实际传输的字节数。例如,

      　　 HTTP/1.1 206 Partial content

       　　Date: Wed, 15 Nov 1995 06:25:24 GMT

       　　Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT

      　　 Content-Range: bytes 21010-47021/47022

      　　 Content-Length: 26012

       　　Content-Type: image/gif

　　当HTTP消息包含多个范围(例如，对多个非重叠范围的请求的响应)的内容时，这些内容做为多部分消息进行传输。用于此目的的大部分媒体类型是附录19.2中定义的“多multipart/byteranges”。兼容性问题见附录19.6.3。

　　对于单个范围的请求的响应不能使用multipart/byteranges媒体类型来发送。对多个范围的请求的响应，若是其结果是单个范围，可能做为带有一个部分的multipart/byteranges媒体类型发送。不能解码multipart/byteranges消息的客户端不能在单个请求中请求多个byte-ranges。

　　当客户端在一个请求中请求多个byte-ranges时，服务器应该按照它们在请求中出现的顺序返回它们。

　　若是服务器因为语法无效而忽略了 byte-range-spec，则服务器应将请求视为不存在无效Range头字段。（一般，这意味着返回包含完整实体的200响应）。

　　若是服务器收到一个请求(除了一个包括If-Range请求头字段)和一个请求头字段不可知足的范围(即全部的byte-range-spec值first-byte-pos值大于当前选中的资源的长度）,它应该返回一个416响应代码(请求的范围不能够知足的)( 10.4.17小节)。

　　注意:对于不可知足Range请求头字段状况，客户端不能依赖服务器发送416(Requested range not satisfiable)响应来代替200 (OK)响应，由于不是全部服务器都支持这个请求头。

14.17 Content-Type

　　Content-Type实体字段表示发送给接收方的实体主体的媒体类型，对于HEAD方法，则表示若是请求是GET，应该发送的媒体类型。

       　　Content-Type   = "Content-Type" ":" media-type

　  媒体类型已经在 3.7小节中定义，下面是该字段的一个例子

      　　 Content-Type: text/html; charset=ISO-8859-4

　　第7.2.1节进一步讨论了肯定实体的媒体类型的方法。

14.18 Date

　　Date通用头字段表示消息产生的日期和时间，跟RFC822中的orig-date同样。该字段的值是一个HTTP—DATE，它的详细描述在 3.3.1小节，它在传输的时候必须被格式化。

      　　 Date  = "Date" ":" HTTP-date

　　下面是一个例子：

      　　 Date: Tue, 15 Nov 1994 08:12:31 GMT

　　源服务器必须在全部的响应中包含一个Date头字段，除了如下的状况：

　　　　1.若是响应的状态码是100或者101，在服务器的配置中，响应中能够包含Date头字段。

　　　　2.若是响应状态代码传递了一个服务器错误，例如500(内部服务器错误)或503(服务不可用)，而且不方便或不可能生成一个有效的日期。

　　　　3.若是服务器没有一个能够提供合理的接近当前时间的值，那么它的响应必定不能包含一个Date头字段，咱们必须遵照 14.18.1小节中的相关规则。

　　若是消息将经过须要Date的协议被接收方或网关缓存，则接收到的没有日期标头字段的消息必须由接收方分配一个Date头字段。没有时钟的HTTP实现不能缓存响应，而且没必要在每次使用时从新验证它们。HTTP缓存，尤为是共享缓存，应该使用NTP等机制来使其时钟与可靠的外部标准同步。

　　客户端应该只在包含entity-body的消息中发送Date头字段，就像PUT和POST请求那样，即便这样，它也是可选的。没有时钟的客户端不能在请求中发送Date头字段。

　　在日期标头中发送的HTTP-date不该该表示消息生成以后的日期和时间。它应该表示消息生成时日期和时间的最佳近似值，除非实现没法生成合理准确的日期和时间。理论上，日期应该表示实体生成以前的时刻。在实践中，日期能够在不影响其语义值的状况下，消息发起期间的任什么时候候生成。

14.18.1 Clockless Origin Server Operation

　　一些原始服务器实现可能没有可用的时钟。没有时钟的原始服务器不能给响应分配Expires或Last-Modified值，除非Date值是由与资源相关联的、具备可靠时钟的系统或用户产生的。它可能分配一个Expires值，该值在服务器配置时或以前是已知的（这使得“pre-expiration”的响应无需单独的存储每一个资源的Expires值）。

14.19 ETag

　　ETAG响应头字段为所请求的变体提供实体标签的当前值。在 14.24, 14.26和 14.44小节中描述了与实体标签一块儿使用的头字段。实体标签可用于与来自同一资源的其余实体进行比较（参见第13.3.3节）。

      　　ETag = "ETag" ":" entity-tag

　　例子:

      　　ETag: "xyzzy"

      　　ETag: W/"xyzzy"

     　　 ETag: ""

14.20 Expect

　　Expect请求头字段被用来描述客户端须要的特定的服务器行为。

     　　 Expect       =  "Expect" ":" 1#expectation

     　　 expectation  =  "100-continue" | expectation-extension

     　　 expectation-extension =  token [ "=" ( token | quoted-string ) *expect-params ]

    　　  expect-params =  ";" token [ "=" ( token | quoted-string ) ]

　　服务器若是没法理解或者遵照任何请求中Expect头字段中的任何存在的预期值，那么应该返回适当的错误状态。服务器必须返回417错误，若是任何的“指望”都没法知足，或者有其余的客户端请求错误，一些4XX错误。

　　该头字段被定义为可扩展的语法，以用在将来可能的扩展中。若是一个服务器接收到了它不支持的Expect头字段中所包含的拓展词（expectation-extension），那么它必须返回一个417错误（Expectation Failed）。

　　“指望”值的比较对于未引用的tokens（包括100-continue）不区分大小写，而且对于引用字符串的指望扩展区分大小写。

　　Expect机制是逐跳（hop-by-hop）的：也就是说，若是HTTP/1.1代理接收到了预期没法知足的请求，则必须返回417（Expectation Failed）状态。可是，预期请求头自己是端到端的；若是转发请求，则必须转发它。

　　许多较老的HTTP/1和HTTP/1.1应用程序不理解Expect头字段。

　　100（continue）状态码的使用方法请查阅8.2.3小节。

14.21 Expires

　　Expires实体头字段给出响应过时的日期/时间。过时的缓存内容一般不会返回缓存机制所缓存的内容(包括代理缓存或用户代理缓存)，除非它首先经过原始服务器(或具备实体的新副本的中间缓存)进行验证。有关到期模型的进一步讨论，请参阅第 13.2节。

　　Expires字段的存在并不意味着原始资源将在该时间节点点以前或以后改变或再也不存在。

　　该字段值的格式是由3.3.1节中的HTTP日期定义的绝对日期和时间；它必须是RFC 1123日期格式：

     　　 Expires = "Expires" ":" HTTP-date

　　下面是一个使用案例

     　　 Expires: Thu, 01 Dec 1994 16:00:00 GMT

　　注意:若是响应包含一个Cache-Control字段和max-age指令(参见14.9.3节)，该指令将覆盖Expires字段。

　　HTTP/1.1客户端和缓存必须处理其余无效的日期格式，特别是包含“0”的值(例如“已过时”)。

　　若是想要将响应标记为“已过时”，那么源服务器须要发送一个等于日期标头值的过时日期。(详情请参阅第 13.2.4节中的过时计算规则。)

　　为了将响应标记为“永不过时”，源服务器发送的Expires日期的值为该响应发送时起的一年后，那么HTTP/ 1.1服务器不该在将来发送超过一年的过时日期。

　　若是Expires头字段的日期值在未来的某个时间出如今默认为不可缓存的响应上，那么表示响应是可缓存的，除非Cache-Control头字段( 14.9小节)另有指示。

14.22 From

　　From请求头字段，若是存在，须要包含一个客户端使用者的互联网邮箱地址。该地址应该是能够被机器识别的“machine-usable”，具体的规则在 RFC 822 [9]并在 RFC 1123 [8]中作了一些升级：

      　　 From   = "From" ":" mailbox

　　下面是一个例子：

　　       From: webmaster@w3.org

　　该头字段可用于日志记录，并可用于标识无效或不想要请求的资源。它不该该用做不安全的访问保护形式。该字段的解释是，请求是表明指定的人所发出的，该人对执行方法负有责任。特别是，机器人代理应该包括这个头，以便在接收端出现问题时能够联系负责运行机器人的人。

　　此字段中的Internet电子邮件地址可能与发出请求的Internet主机分开。例如，当请求经过代理传递时，应该使用原始发布者的地址。

　　客户端不该该在未经用户批准的状况下发送From头字段，由于这可能会与用户的隐私利益或其站点的安全策略发生冲突。强烈建议用户可以在请求以前的任什么时候候禁用、启用和修改此字段的值。

14.23 Host

　　Host 请求头字段指定了从用户给出的原始URI或引用资源（一般是HTTP URL，如3.2.2节所述）中所得到的被请求资源的网络主机和端口号。HOST字段值必须表明原始URL给出的源服务器或网关的命名权限。这容许原始服务器或网关区份内部模糊的（内部歧义）URL，例如，用于单个IP地址上的多个主机名的服务器URL的根名称“/”。

      　　 Host = "Host" ":" host [ ":" port ] ; Section 3.2.2

　　若是一个host尾部并无跟随端口号信息，那么就是默认的端口号（好比，HTTP URl的默认端口号是80）。举个例子。向“http://www.w3.org/pub/WWW”所发出的请求会包含如下信息：

       　　GET /pub/WWW/ HTTP/1.1

       　　Host: www.w3.org

　　在HTTP/1.1的客户端请求信息中必须包含HOST头字段。若是所请求的URI不包括所请求服务的Internet主机名，则必须给Host头字段一个空值。HTTP/1.1代理必须确保它转发的任何请求信息中都包含适当的HOST头字段，该字段标识代理请求的服务。全部基于HTTP/1.1的互联网请求的服务器必须对任何缺乏主机头字段的HTTP/1.1请求消息使用400（Bad Request）状态码进行响应。

　　有关HOST字段的其余要求见第5.2和19.6.1.1 节。

14.24 If-Match

　　If-Match请求头字段须要与一个使其成为“条件”的方法一块儿使用。拥有一个或多个以前从资源中得到的实体的客户端能够经过在If-Match头字段中包含相关实体标记的列表来验证这些实体中的一个是不是当前匹配的。实体标记在 3.11节中有详细说明。这个特性的目的是容许以最少的开销，高效地更新缓存的信息。在更新请求时，它还用于防止无心中修改错误版本的资源。做为一种特殊状况，“*”值匹配资源的任何当前实体。

       　　If-Match = "If-Match" ":" ( "*" | 1#entity-tag )

　　若是任何实体标记与在响应该资源上的相似GET请求（没有if-Match头字段）时返回的实体的实体标记相匹配，或者若是“*”值在IF-Matc中被给出而且任何当前的实体都存在该资源中，则服务器能够执行所请求的方法就像if-Match头字段不存在同样。

　　服务器必须使用强比较函数（参见第 13.3.3节）来比较If-Match中的实体标签。

　　若是没有匹配的实体标记，或者给定了“*”值，且不存在当前实体，服务器就不能执行请求的方法，必须返回412(Precondition Failed)响应。当客户端但愿阻止一个更新类型的方法(如PUT)修改自客户端上次检索后已更改的资源时，这种行为最有用。

　　若是请求在没有if-Match头字段的状况下会致使除了2xx或412状态以外的任何结果，则必须忽略if-Match头字段。

　　“if-Match：*”的含义是，若是源服务器(或缓存，可能使用变体机制，请参见14.44节)选择的内容存在，则应该执行该方法，若是内容不存在，则必须不执行该方法。

　　更新资源(例如PUT)的请求可能包含if-match头字段，以表示若是与if-match值(单个实体标记)对应的实体再也不是该资源的表示，则不得应用请求方法。这容许用户表示，若是资源在他们不知情的状况下被更改，他们不但愿请求成功。

　　例如：

      　　 If-Match: "xyzzy"

       　　If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"

     　　  If-Match: *

　　一个请求中是否能够同时存在If-Match字段和If-None-Match或If-Modified-Since头字段在本规范中并未定义。

14.25 If-Modified-Since

　　If-Modified-Since请求头字段须要与一个使其成为“条件”的方法一块儿使用：若是请求变量在该字段给出的时间范围内没有被修改，那么服务器则不能返回实体内容。替代的，一个没有任何信息体的304（Not Modified）响应会被返回。

       　　If-Modified-Since = "If-Modified-Since" ":" HTTP-date

　　下面是该字段的一个例子：

      　　 If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

　　一个带有If-Modified-Since头字段且没有Range头字段的GET方法只要求标识的实体在If-Modified-Since头字段给出的日期以后被修改，才会被传递。肯定这一点的算法包括下列状况:　　

      　　a) 若是请求一般不会致使200 (OK)状态，或者传递的If-Modified-Since日期无效，则响应与普通GET彻底相同。晚于服务器当前时间的日期无效。

     　　 b) 若是该变体自If-Modified-Since所携带的日期以来进行了修改，则响应与普通GET彻底相同。

     　　 c)若是该变体在有效的If-Modified-Since日期以后没有被修改，服务器应该返回304(没有修改)响应。

　　这个特性的目的是容许以最少的事务开销来更高效地更新缓存的信息。

　　　　注意：Range请求头字段会修改If-Modified-Since的含义。详情请见14.35小节。

      　　注意:由于时间是由服务器肯定的，服务器的时间可能与客户端的时间不一样步。

　　　　注意：在处理If-Modified-Since头字段时，一些服务器将使用精确的日期比较函数而不是小于函数来决定是否发送304(未修改)响应。为了得到最好的结果，当发送一个If-Modified-Since头字段来进行缓存验证时，建议客户端尽量使用在上一个Last-Modified头字段中收到的确切日期字符串。

　　　　注意：若是客户端在If-Modified-Since头字段中使用任意日期，而不是使用从同一个请求的Last-Modified头字段中提取的日期，那么客户端应该知道这个日期是用服务器中的时间来作为解释的。因为客户端和服务器之间的时间并不相同，客户端须要考虑不一样步时钟和舍入问题。这包括，若是文档在第一次请求的时间和后续请求中存在If-Modified-Sinc日期之间发生了更改，那么可能存在竞态条件;若是If-Modified-Since日期来自客户端的时钟，且并无修改服务器的时钟，则可能存在时钟偏移相关的问题。因为网络延迟，客户端和服务器之间的不一样时间间隔即便在修正后也不可能彻底同样。

　　一个请求中是否能够同时存在If-Match字段和If-None-Match或If-Modified-Since头字段在本规范中并未定义。

14.26 If-None-Match

　　If-None-Match请求头字段须要与一个使其成为“条件”的方法一块儿使用。拥有一个或多个先前从资源中得到的实体的客户端能够经过在If-None-Match头字段中包含相关实体标记的列表来验证这些实体都不是当前的。这个特性的目的是容许以最少的事务开销来高效地更新缓存的信息。它还用于防止客户端认为资源不存在时在无心中使用一些方法修改现有资源(例如PUT)。

做为一种特殊状况，“*”值匹配资源的任何当前实体。

       If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )

　　若是任何实体标记匹配该实体标记，那么将会致使在使用一个相似GET请求(不具备If-None-Match请求头)下的资源被返回，或者给出的If-None-Match请求头字段的值时*号而且当前存在任何属于该资源的实体，除非必要不然服务器必定不能执行所请求的方法，由于在If-Modified-Since请求头字段中资源的修改日期是不匹配的。。相反，若是请求方法是GET或HEAD，服务器应该使用304(未修改)响应进行响应，包括与缓存相关的头字段(特别是与ETag匹配的一个实体)。对于全部其余请求方法，服务器必须以412状态响应(Precondition Failed)。

　　有关如何肯定两个实体标记是否匹配的规则，请参阅第13.3.3节。弱比较函数只能用于GET或HEAD请求。

　　若是实体标记都不匹配，那么服务器能够执行请求的方法，就好像If-None-Match头字段不存在同样，可是必须忽略请求中存在的任何If-Modified-Since头字段。也就是说，若是没有实体标记匹配，服务器就不能返回304(Not Modified)响应。

　　若是请求在没有If-None-Match头字段的状况下，结果不是2xx或304状态，则必须忽略If-None-Match标头。(请参阅第13.3.4节，了解在同一请求中同时出现If-Modified-Since和If-None-Match时的服务器行为。)

　　“If-None-Match: *”的意思是，若是原始服务器(或缓存可能使用变体机制，请参见14.44节)选择的表示存在，则不能执行该方法，若是表示不存在，则应该执行该方法。这个特性用于防止PUT操做之间的竞争。

例子:

       If-None-Match: "xyzzy"

       If-None-Match: W/"xyzzy"

       If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"

       If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"

       If-None-Match: *

　　一个请求中是否能够同时存在If-Match字段和If-None-Match或If-Modified-Since头字段在本规范中并未定义。

14.27 If-Range

　　若是客户端在其缓存中有一个实体的部分副本，而且但愿在其缓存中有整个实体的最新副本，那么它可使用Range 请求头和一个有条件的GET(使用If-Unmodified-Since和If-Match)。可是，若是因为实体被修改而致使条件失败，那么客户端将不得不发出第二次请求以得到整个当前实体主体。

　　If-Range报头容许客户端“短路（short-circuit）”第二个请求。非正式地说，它的意思是“若是实体没有改变，就把我缺乏的部分发给我;不然，将整个新实体发送给我”。

        If-Range = "If-Range" ":" ( entity-tag | HTTP-date )

　　若是客户端没有实体的实体标记，可是有最后修改日期，它能够在If-Range头字段中使用该日期。(服务器能够经过检查不超过两个字符来区分有效的HTTP-date和任何形式的实体标记。)If-Range头字段应该只与Range头字段一块儿使用，若是请求不包含Range头字段，或者服务器不支持子范围操做，则必须忽略该报头。

If the entity tag given in the If-Range header matches the current entity tag for the entity, then the server SHOULD provide the specified sub-range of the entity using a 206 (Partial content) response. If the entity tag does not match, then the server SHOULD return the entire entity using a 200 (OK) response.

　　若是If-Range头字段中的实体标记与实体的当前实体标记匹配，那么服务器应该使用206(Partial content)响应提供实体的指定子范围。若是实体标记不匹配，那么服务器应该使用200 (OK)响应返回整个实体。

14.28 If-Unmodified-Since

　　If-Unmodified-Since请求头字段须要与一个使其成为“条件”的方法一块儿使用。若是请求的资源在此字段中指定的时间以后没有被修改，服务器应该执行请求的操做，就像If-Unmodified-Sincee头文件不存在同样。

　　若是请求的变体自指定时间以来已经被修改，服务器必须不执行请求的操做，而且必须返回412(Precondition Failed)状态。

      　　If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date

　　下面是该字段的一个例子:

       　　If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

　　若是在请求正常(例如，请求中没有If-Unmodified-Since报头)的状况下，，可能会产生除了2xx或412状态外的其余任何状态，那么If-Unmodified-Since报头应该被忽略。

　　若是指定的日期无效，则忽略该头字段。

　　此规范未定义具备If-Unmodified-Since标头字段和If-None-Match或If-Modified-Since标头字段的请求的结果。

14.29 Last-Modified

　　Last-Modified实体头字段指示原始服务器认为该变体最后被修改的日期和时间。

       　　Last-Modified  = "Last-Modified" ":" HTTP-date

下面是该字段的是个用法例子：

      　　 Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

　　这个头字段的确切含义取决于原始服务器的实现和原始资源的性质。对于文件，可能只是文件系统最后一次修改的时间。对于包含动态部件的实体，它多是其组件部件的最后一次修改时间集的最近一次修改时间集。对于数据库网关，它多是记录的最后更新时间戳。对于虚拟对象，多是最后一次更改的内部状态。

　　源服务器不能发送晚于服务器发出消息时间的Last-Modified日期。在这种状况下，若是资源的最后一次修改将指示未来的某个时间，则服务器必须将该日期替换为消息发起日期。

　　原始服务器应该包含尽量接近于实体生成响应的时间的日期值的Last-Modified值。这容许接收方准确评估实体的修改时间，特别是当实体在生成响应时发生更改。

　　HTTP/1.1服务器应该在可行的状况下发送Last-Modified。

14.30 Location

　　Location 响应头字段用于将收件人重定向到请求uri之外的位置，以完成请求或标识新资源。对于201(Created)响应，Location是由请求建立的新资源的位置。对于3xx响应，Location应该指示服务器自动重定向到资源的首选URI。字段值由单个绝对URI组成。

      　　 Location       = "Location" ":" absoluteURI

　　例子:

       　　Location: http://www.w3.org/pub/WWW/People.html

　　注意:Content-Location头字段(14.14节)与Location不一样，由于Content-Location标识了请求中包含的实体的原始位置。所以，响应能够包含Location和Content-Location的头字段。某些方法的缓存要求参见第13.10节。

14.31 Max-Forwards

　　Max-Forwards请求头字段为TRACE(9.8节)和OPTIONS(9.2节)方法提供了一种机制，用于限制能够将请求转发到下一个入站服务器的代理或网关的数量。当客户端试图跟踪请求链时，若是请求链在中间链中出现故障或循环，这可能很是有用。

      　　 Max-Forwards   = "Max-Forwards" ":" 1*DIGIT

　　最大转发值是一个十进制整数，指示此请求消息可能被转发的剩余次数。

　　TRACE或OPTIONS请求的每一个代理或网关接收者(包含Max-Forwards头字段)必须在转发请求以前检查并更新其值。若是接收到的值为0，接收方不得转发请求;相反，它必须做为最终接收者作出回应。若是接收到的Max-Foewards值大于零，那么转发的消息必须包含一个更新的Max-Foewards字段，其值递减为1。

　　对于本规范中定义的全部其余方法和那些没有明确地将其做为该方法定义的一部分的扩展方法来讲，Max-Forwards头字段均可能被忽略。

14.32 Pragma

　　Pragma通用头字段用于包含可能应用于请求/响应链上任何接收者的特别的指令。全部实用程序指令从协议的角度指定可选行为;然而，一些系统可能要求行为与指令一致。

      　　 Pragma            = "Pragma" ":" 1#pragma-directive

      　　 pragma-directive  = "no-cache" | extension-pragma

      　　 extension-pragma  = token [ "=" ( token | quoted-string ) ]

　　当请求消息中出现no-cache指令时，应用程序应该将请求转发到原始服务器，即便它有被请求内容的缓存副本。这个pragma指令具备与no-cache缓存指令相同的语义(参见14.9节)，它的定义是为了向后兼容HTTP/1.0。当一个没有缓存的请求被发送到一个不知道是否兼容HTTP/1.1的服务器时，客户端应该包含这两个头字段。

　　Pragma指令必须经过代理或网关应用程序传递，而无论它们对应用程序的重要性如何，由于这些指令可能适用于请求/响应链上的全部接收者。不可能为特定的接收者指定一个实用程序;然而，任何与接收者无关的Pragma指令都应该被接收者忽略。

　　HTTP/1.1缓存应该将“Pragma: no-cache”视为客户端发送的“Cache-Control: no-cache”。HTTP中不会定义新的Pragma指令。

　　注意:由于“Pragma: no-cache”做为响应头字段的含义实际上没有指定，因此它不能替换响应中的“Cache-Control: no-cache”头字段。

14.33 Proxy-Authenticate

　　Proxy Authenticate 响应头字段必须被包含在一个407（Proxy Authentication Required）响应中。字段值包含一个“询问”，该“询问”指示这个请求URI的代理适用的身份验证方案及参数。

       　　Proxy-Authenticate  = "Proxy-Authenticate" ":" 1#challenge

　　HTTP访问身份验证过程被描述为“HTTP身份验证:基本和摘要访问身份验证”[43]。与WWW-Authenticate不一样，代理身份验证头字段仅应用于当前链接，不该传递到下游客户端。可是，中间代理可能须要经过从下游客户端请求它们来得到本身的凭证，在某些状况下，这看起来就好像代理在转发Proxy-Authenticate头字段同样。

14.34 Proxy-Authorization

　　Proxy-Authorization请求头字段容许客户端将本身(或其用户)标识给须要身份验证的代理。Proxy-Authorization字段值由凭证组成，该凭证包含用户代理的身份验证信息，用于请求的资源和/或领域。

      　　 Proxy-Authorization     = "Proxy-Authorization" ":" credentials

　　HTTP访问身份验证过程在“HTTP Authentication:基本和摘要访问身份验证”[43]中有更详细的描述。与Authorization不一样，Proxy-Authorization头字段仅适用于使用Proxy- Authenticate字段要求进行身份验证的下一个出站代理。当在一个链中使用多个代理时，Proxy-Authorization头字段将由第一个指望接收凭证的出站代理使用。代理能够将凭证从客户端请求中继到下一个代理，若是这是代理合做验证给定请求的机制的话。

14.35 Range

14.35.1 Byte Ranges(字节范围)

　　因为全部HTTP实体在HTTP消息中都表示为字节序列，所以字节范围的概念对任何HTTP实体都有意义。(不过，并不是全部客户端和服务器都须要支持字节范围操做。)

　　HTTP中的字节范围规范适用于实体主体中的字节序列（不必定与消息主体相同）。

　　字节范围操做能够指定单个范围的字节，或者指定单个实体中的一组范围。

      　　 ranges-specifier = byte-ranges-specifier

      　　 byte-ranges-specifier = bytes-unit "=" byte-range-set

　　       byte-range-set  = 1#( byte-range-spec | suffix-byte-range-spec )

　　       byte-range-spec = first-byte-pos "-" [last-byte-pos]

　　       first-byte-pos  = 1*DIGIT

　　       last-byte-pos   = 1*DIGIT

　　在byte-range-spec中给定的first-byte-pos值是第一个字节范围。last-byte-pos给定的是最后一个字节的范围。也就是说，指定的字节位置包括在内。字节的范围从0开始。

　　若是last-byte-pos存在，在byte-range-spec中必须大于或等于first-byte-pos，不然byte-range-spec规范在语法上是无效的。包含一个或多个语法无效的byte-range-spec值的byte-range-set的接收者必须忽略包含该byte-range-set的标头字段。

　　若是不存在last-byte-pos值，或者若是该值大于或等于实体主体的当前长度，则last-byte-pos的值被取为小于实体主体的当前长度的字节。

　　经过选择last-byte-pos，客户端能够在不知道实体大小的状况下限制检索的字节数。

      　　 suffix-byte-range-spec = "-" suffix-length

       　　suffix-length = 1*DIGIT

　　suffix-byte-range-spec被用来用于指定实体主体的后缀，其长度由suffix-length值给出。(也就是说，该结构指定实体主体的最后N字节。)若是实体短于指定的suffix-length，则使用整个实体主体。

　　若是一个语法有效的byte-range-set包含至少一个byte-range-spec，其first-byte-pos小于实体主体的当前长度，或者至少一个非零的suffix-byte-range-spec，那么byte-range-set是可知足的。不然， byte-range-se是没法知足的。若是byte-range-set没法知足，服务器应该返回状态为416的响应(Requested range not satisfiable)。不然，服务器应该返回状态为206(Partial Content)的响应，其中包含实体主体的可知足范围。　　

　　下面是一个指定字节范围值的例子（假定实体主体的长度是10000）:

     　　 - 最开始的500个字节 (字节范围是 0-499, 包含开始和结束的值):  bytes=0-499

      　　- 第二部分500个字节 (字节范围是 500-999, 包含开始和结束的值):bytes=500-999

      　　- 最后500个字节 (字节范围是 9500-9999, 包含开始和结束的值):bytes=-500

      　　- 或者 bytes=9500-

      　　- 只有第一个和最后一个字节 (字节 0 和 9999):  bytes=0-0,-1

     　　 -  (字节范围 500-999, 包含开始和结束的值)下面是几个合法但不规范的第二部分字节的表示方法:

　　 　　　　bytes=500-600,601-999

       　　　　bytes=500-700,601-999

14.35.2 Range Retrieval Requests（范围检索请求）

　　使用条件或无条件GET方法的HTTP检索请求可使用Range请求头请求实体的一个或多个子范围，而不是整个实体，它适用于做为请求结果返回的实体:

      　　Range = "Range" ":" ranges-specifier

　　服务器可能忽略Range头字段。然而，HTTP/1.1源服务器和中间缓存应该尽量支持字节范围，由于Range头字段支持对部分失败传输的高效恢复，而且支持对大型实体的高效部分检索。

　　若是服务器支持Range头字段，而且指定的范围适合实体:

　　　　- 无条件GET中出现的Range头字段会修改GET请求成功返回的内容。换句话说，响应的状态代码是206(Partial Content)，而不是200 (OK)。

　　　　- 有条件的GET请求(使用If-Modifify-Since或者If-None-Match中一个或两个的请求，或者If-Unmodify-Since和If-Match中一个或两个的请求)中存在的Range头字段能够修改若是GET成功且条件为true时返回的内容。若是条件为false，则不影响返回的304(Not Modified)响应。

　　在某些状况下，除了Range头字段以外，使用If-Range头字段(参见14.27节)可能更合适。

　　若是支持范围的代理接收范围请求，将请求转发到入站服务器，并接收整个实体做为响应，那么它应该只将请求范围返回给客户端。若是响应与缓存分配策略一致，则应该将整个接收到的响应存储在缓存中。

14.36 Referer

　　Referer[sic]请求头字段容许客户端为服务器的着想的角度指定获取请求URI的资源的地址(“referrer”，尽管头字段拼错了)。Referer请求头容许服务器为感兴趣的资源生成返回连接列表，日志记录，优化缓存等等。它也容许对过期的或输入错误的连接进行跟踪以进行维护。若是从没有本身的URI(例如从用户键盘输入)的源获取请求URI，则不能发送Referer字段。

      　　 Referer  = "Referer" ":" ( absoluteURI | relativeURI )

　　例子：

       　　Referer: http://www.w3.org/hypertext/DataSources/Overview.html

　　若是字段值是一个相对URI，则应该将其解释为相对于请求URI。URI不能包含片断。有关安全方面的参考，请查看第15.1.3小节。

14.37 Retry-After

　　Retry-After 响应头字段可与503(Service Unavailable)响应一块儿使用，以指示请求客户端预期服务不可用的时间。此字段还能够与任何3xx(Redirection)响应一块儿使用，以指示用户代理在发出重定向请求以前等待的最短期。该字段的值能够是HTTP-date值，也能够是响应时间以后的整数秒数(十进制)。

　　       Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds )

　　下面是该字段用法的两个例子

   　　    Retry-After: Fri, 31 Dec 1999 23:59:59 GMT

   　　    Retry-After: 120

　　第二个例子，须要延迟两分钟

14.38 Server

The Server response-header field contains information about the software used by the origin server to handle(操做，操控;) the request. The field can contain multiple product tokens (section3.8) and comments identifying(确认;辨认;认出) the server and any significant subproducts(子积;子乘积;[). The product tokens are listed in order of their significance(意义;重要性;意思) for identifying the application.

       　　Server         = "Server" ":" 1*( product | comment )

　　例子:

      　　 Server: CERN/3.0 libwww/2.17

If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it SHOULD include a Via field (as described in section 14.45).

      Note: Revealing(泄露;显示，展现;揭示，揭露) the specific software version of the server might allow the server machine to become more vulnerable(易受攻击的;易受伤的;易受批评的;[桥牌]已成局的) to attacks against software that is known to contain security holes. Server implementors(实现者) are encouraged(鼓动;鼓励) to make this field a configurable(结构的，可配置的) option.

14.39 TE

　　TE请求头字段指示它愿意在响应中接受哪些扩展传输编码，以及是否愿意接受分组传输编码中的trailer字段。它的值可能包括关键字“trailers”和（或）带有可选接收参数的以逗号分隔的扩展传递编码名称列表(如3.6节所述)。

       　　TE  = "TE" ":" #( t-codings )

       　　t-codings = "trailers" | ( transfer-extension [ accept-params ] )

　　关键字“trailers”的出现代表客户愿意接受分段转换编码中的trailer字段，如 3.6.1节中定义的那样。这个关键字保留用于传输编码值，即便它自己并不表示传输编码。

　　它的用法:

      　　 TE: deflate

　　       TE:

      　　 TE: trailers, deflate;q=0.5

　　TE头字段仅适用于短链接（immediate connection）。所以，当HTTP/1.1消息中出现TE时，必须在链接标头字段(14.10小节)中提供关键字。

　　根据TE字段，服务器使用如下规则测试传输编码是否可接受:

      　　1. “chunked”的转换编码老是能够接受的。若是列出了关键字“trailers”，则客户端表示它愿意表明本身和任何下游客户接受chunked响应中的trailer字段。这意味着，若是给定，客户端将声明，要么全部下游客户端都愿意接受转发响应中的trailers字段，要么它将尝试表明下游接收者缓冲响应。

　　　　注意:HTTP/1.1没有定义任何方法来限制chunked响应的大小，从而确保客户端可以缓冲整个响应。

      　　2.若是正在测试的传输编码是TE字段中列出的传输编码之一，那么它是能够接受的，除非qvalue的值为0。(在3.9节中定义，0的qvalue值表示“不可接受”。)

     　　 3. 若是多个传输编码是可接受的，则首选具备最高非零qvalue值的可接受传输编码。“chunked”转换编码的qvalue值老是为1。

　　若是TE字段值为空或不存在TE字段，则惟一的传输编码是“chunked”。没有传输编码的消息老是能够接受的。

14.40 Trailer

　　Trailer通用头字段值用来表示给定的头字段集存在于用分块“传输编码”编码的消息的trailer中。

       　　Trailer  = "Trailer" ":" 1#field-name

　　HTTP/1.1消息应该包含消息中的Trailer头字段，该字段使用非空Trailer的分组传输编码。这样作可让接收者知道Trailer中指望的是哪一个头字段。

If no Trailer header field is present, the trailer SHOULD NOT include any header fields. See section 3.6.1 for restrictions on the use of trailer fields in a "chunked" transfer-coding.

　　若是不存在Trailer头字段，那么trailer不该该包含任何头字段。请参阅第3.6.1节，了解在“chunked”传输编码中使用trailer字段的限制。

　　在Trailer头字段中列出的消息头字段不能包含如下头字段:

      . Transfer-Encoding

      . Content-Length

      . Trailer

14.41 Transfer-Encoding

　　Transfer-Encoding 通用头字段指示向消息体应用了什么（若是有的话）类型的转换，以便在发送方和接收方之间安全地传输它。这与内容编码不一样，由于传输编码是消息的属性，而不是实体的属性。

     　　Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-coding

　　Transfer-codings在 3.6小节中有详细的定义。下面是一个例子：

     　　Transfer-Encoding: chunked

　　若是多个编码被应用到一个实体，那么传输编码必须按照应用它们的顺序列出。有关编码参数的其余信息能够由本规范未定义的其余实体头字段提供。

　　大多数应用HTTP/1.0的协议没法理解Transfer-Encoding头字段。

14.42 Upgrade

　　Upgrade通用头字段容许客户端指定它支持哪些附加通讯协议，若是服务器发现它适合交换协议，则容许客户端使用哪些附加通讯协议。服务器必须在101（Switching Protocols）响应中使用Upgrade头字段来指示正在交换哪些协议。

      　　 Upgrade        = "Upgrade" ":" 1#product

　　例如,

      　　 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

　　Upgrade头字段旨在提供一个简单的机制，用于从HTTP/1.1转换到其余不兼容的协议。它经过容许客户端声明它想要使用另外一种协议来实现这一点，好比使用更高主版本号的HTTP的后期版本，即便当前的请求是使用HTTP/1.1发出的。这经过容许客户端在更广泛支持的协议中发起请求，同时向服务器指示若是可用，它但愿使用“更好”的协议（“更好”由服务器决定，可能根据所请求的方法和/或资源的性质不一样而不一样。），从而减轻了不兼容协议之间转换困难的问题。

　　Upgrade头字段仅适用于现有传输层链接上的交换应用层协议。Upgrade不能用于坚持更改协议；服务器的接受和使用是可选的。协议改变后的应用层通讯的能力和性质彻底取决于所选择的新协议，尽管改变协议以后的第一动做必须是对包含Upgrade头字段的初始HTTP请求的响应。

　　Upgrade头字段仅适用于当即链接。所以，每当在HTTP/1.1消息中存在Upgrade时，必须在Connection头字段（部分14.10）中提供upgrade关键字。

　　Upgrade头字段不能用于指示在不一样链接上切换协议。为此，使用301, 302, 303或305等重定向响应更合适。

　　本规范只定义了供超文本传输协议族使用的协议名称“HTTP”，如3.1节的HTTP版本规则和本规范的将来更新所定义。任何令牌均可以用做协议名称；可是，只有当客户端和服务器都把该名称与相同的协议关联时才有用。

14.43 User-Agent

　　User-Agent请求头字段包含关于发起请求的用户代理的信息。这是为了统计请求的意图、跟踪违反协议的状况以及自动识别用户代理，以便调整响应以免特定的用户代理限制。用户代理应该将此字段包含在请求中。字段能够包含多个产品标记(第3.8节)和标识代理和构成用户代理重要部分的任何子产品的注释。按照惯例，产品令牌是按照它们对识别应用程序的重要性列出的。

      　　 User-Agent = "User-Agent" ":" 1*( product | comment )

　　例子:

　　       User-Agent: CERN-LineMode/2.15 libwww/2.17b3

14.44 Vary

　　Vary字段值表示请求头字段集，该字段集在响应是“新鲜”的状况下彻底肯定是否容许缓存使用响应来响应后续请求，而无需从新验证。对于没法缓存或过期的响应，Vary字段值向用户代理提供用于选择表示的标准。值“*”表示缓存没法从后续请求的请求头中肯定此响应是否合适。请参阅第 13.6节，了解缓存对Vary头字段的使用。

       　　Vary  = "Vary" ":" ( "*" | 1#field-name )

　　HTTP/1.1服务器应该包含一个Vary头字段，其中包含任何可缓存的响应，该响应受服务器驱动协商的影响。这样作容许缓存正确地解释对该资源的将来请求，并告知用户代理该资源上是否存在协商。服务器可能包含一个Vary标头字段，其中不可缓存的响应受服务器驱动协商的影响，由于这可能为用户代理提供关于“响应”在响应时变化的维度的有用信息。

　　一个Vary字段值，由一组字段名称信号组成，所选的响应表示是基于选择算法的，该算法在选择最合适的表示时只考虑列出的请求头字段。缓存可能假设在响应新鲜的时间段内，对于未来具备相同值的请求，将进行相同的选择。

　　给出的字段名不限于此规范定义的标准请求头字段集。且字段名不区分大小写。

　　若是Vary的字段值是“*”，则代表未指定的参数不限于请求头(例如，客户端的网络地址)，在响应表示的选择中起做用。“*”值不能由代理服务器生成;它可能仅由原始服务器生成。

14.45 Via

　　Via通用头字段必须被网关和代理使用，以用来在请求中指示用户代理和服务器之间的中间协议和接收者，在响应上指示源服务器和客户端之间的中间协议和接收者。它相似于RFC 822[9]的“Received”字段，用于跟踪消息转发，避免请求循环，以及识别请求/响应链上全部发送者的协议功能。

      　　Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )

      　　received-protocol = [ protocol-name "/" ] protocol-version

      　　protocol-name     = token

     　　 protocol-version  = token

      　　received-by       = ( host [ ":" port ] ) | pseudonym

     　　 pseudonym         = token

　　接收协议指示服务器或客户端沿着请求/响应链的每一个环节所接收的消息相关的协议版本。当消息被转发时，接收的协议版本被附加到Via字段的值上，以便关于上游应用程序的协议能力的信息对全部接收者保持可见。

　　协议名称是可选的，当且仅当它是“HTTP”时。接收方字段一般是随后转发消息的接收方服务器或客户端的主机和可选端口号。然而，若是真实主机被认为是敏感信息，它能够被化名取代。若是没有给出端口，则能够假定它是接收到的协议的默认端口。

　　多个Via字段值表示转发消息的每一个代理或网关。每一个接收方必须附加其信息，以便根据转发应用程序的序列对最终结果进行排序。

　　注释能够在Via头字段中使用，以标识接收方代理或网关的软件，相似于User-Agent和Server标头字段。可是，在传递字段中的全部注释都是可选的，而且能够在转发消息以前由任何接收者删除。

　　例如，能够将请求消息从HTTP/1.0用户代理发送到名为“fred”的内部代理，该代理使用HTTP/1.1将请求转发到nowhere.com的公共代理，该公共代理经过将请求转发到位于www.ics.uci.edu的源服务器来完成请求。由www.ics.uci.edu接收的请求将具备如下的Via头字段：

       　　Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

　　默认状况下，代理和网关做为经过网络防火墙的门户不该该转发防火墙区域内的主机的名称和端口。只有显式启用该信息才能传播。若是没有启用，防火墙后面的任何主机的主机所接收的主机都应该用适当的化名替换。

　　对于对隐藏内部结构具备很强隐私要求的组织，代理能够将具备相同接收协议值的Via头字段条目的有序子序列组合到一个这样的条目中。例如，

       　　Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

　　能够缩减为

       　　Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

　　应用程序不该该组合多个条目，除非它们都在相同的组织控制之下，而且主机已经被假名取代。应用程序不能组合具备不一样接收的协议值的条目。

14.46 Warning

　　Warning通用头字段用于承载关于消息中可能未反映的消息的状态或转换的附加信息。此信息用于警告实体主体信息在缓存配置或转换中缺少语义的透明度。

　　Warning头字段经过如下方式发送:

       　　Warning    = "Warning" ":" 1#warning-value

       　　warning-value = warn-code SP warn-agent SP warn-text

                                             　　[SP warn-date]

       　　warn-code  = 3DIGIT

       　　warn-agent = ( host [ ":" port ] ) | pseudonym

                      　　 ; 服务器添加的名称或别名

                      　　 ; Warning头字段，用于调试

       　　warn-text  = quoted-string

       　　warn-date  = <"> HTTP-date <">

　　响应可能包含多个Warning头字段。

　　警告文本应该使用天然语言和字符集，对于接收响应的人类用户来讲，这些语言和字符集最容易理解。此决策能够基于任何可用的知识，例如缓存或用户的位置、请求中的Accept-Language字段、响应中的Content-Language字段等。默认语言为英语，默认字符集为ISO-8859-1。

　　若是使用的字符集不是ISO-859-1，则必须使用RFC 2047（14）中描述的方法在警告文本中进行编码。

　　Warning头一般能够应用于任何消息，可是一些特定的警告代码对于缓存来讲是特殊的，而且只能应用于响应消息。在任何现有的Warning标头以后都应该添加新的警告标题。缓存不能删除它收到的任何消息头。可是，若是缓存成功验证缓存条目，则应删除之前附加到该条目的任何Warning标头，除非为特定Warning代码指定。而后，必须在验证响应中添加任何Warning标头。换句话说，Warning标头是那些附加到最近的相关响应的标题。

　　当多个Warning头附加到响应时，用户代理应该尽量多地通知用户，以使它们出如今响应中。若是没法将全部警告通知用户，用户代理应遵循如下启发式方法:

     　　 - 出如今响应中较早的警告优先于出如今响应中较晚的警告。

      　　- 用户首选字符集中的警告优先于其余字符集中的警告，可是警告代码和警告代理是相同的。

　　生成多个Warning标头的系统应该根据用户代理行为对其进行排序。

　　有关警告的缓存行为的需求在第13.1.2节中说明。

　　这是当前定义的警告代码的列表，每一个警告代码都带有英文推荐的警告文本，并描述了其含义。

　　　　110 - 当响应过时时，则必须被包含。

　　　　111 - 若是因为没法链接到服务器而引发的重校验失败致使了缓存返回了一个陈旧的响应，则“从新校验失败”必须被包含。

　　　　112 - 若是缓存有意从网络的其他部分断开一段时间，则应该包含“断开链接操做”。

　　　　113 - 若是缓存从启发意义上选择的新鲜度范围大于24小时，响应的范围大于24小时。则“探索性过时”必须被包含。

　　　　199 - 杂项警告，警告文本能够包括要呈现给人类用户或登陆的任意信息。接受此警告的系统除了向用户发出警告外，不得采起任何自动化行动。

　　　　214 - 应用转换必须由中间缓存或代理添加，若是它应用任何转换来更改响应的内容编码（如Content-Encoding标头中指定的）或媒体类型（如Content-Type标头中指定的）或响应的实体主体，除非该Warning字段已经出如今响应中。

　　　　299 - 杂项持久警告，警告文本能够包括要呈现给人类用户或登陆的任意信息。接收此警告的系统不能采起任何自动化操做。

　　若是实现发送的消息具备一个或多个警告标头，其版本为HTTP/1.0或更低，那么发送方必须在每一个警告值中包含一个与响应中的日期匹配的警告日期。

　　若是一个实现接收到包含警告日期的警告值的消息，而且该警告日期与响应中的日期值不一样，那么在存储、转发或使用消息以前，该警告值必须从消息中删除。(这能够防止警告标头字段初始缓存的不良后果。)若是出于这个缘由删除了全部警告值，那么警告头也必须被删除。

14.47 WWW-Authenticate

　　WWW-Authenticate响应头字段必须包含在401(Unauthorized)响应消息中。字段值由至少一个询问组成，该询问指示身份验证方案和适用于Request-URI的参数。

　　       WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge

　　HTTP访问身份验证过程描述为“HTTP身份验证:基本和摘要访问身份验证”[43]。建议用户代理在解析WWW-Authenticate字段值时特别当心，由于它可能包含多个质询，或者若是提供了多个WWW-Authenticate头字段，则质询自己的内容能够包含一个逗号分隔的身份验证参数列表。