如果请求经过缓存和请求URI识别一个或多个当前缓存的实体,这些实体将被抛弃.这个方法的应答是不可缓存的.
如果请求经过缓存和请求URI识别一个或多个当前缓存的实体,这些实体将被抛弃.这个方法的应答是不可缓存的.
如果请求经过高速缓冲存储器和请求URI标识一个或多个当前缓存的实体,这些实体将被抛弃.这个方法的应答是不可缓存的.
9.8 TRACE（跟踪）
TRACE方法用于调用远程的,应用层循环请求消息.请求最终的接收者应当反射从客户机作为200应答的实体正文收到的信息.最终的接收者也是原服务器或在请求中收到最大转发数量值第一个代理服务器或网关 (看14.31节).TRACE请求不包括实体.
TRACE允许客户端了解在请求的另一端收到的内容和用数据测试或诊断信息.经由报头域的值尤其重要,因为它表示请求过程的路径.最大转发数域的使用允许客户端限制请求链的长度,这对在无限循环中找出前向路径的代理服务器是很有用的.
如果请求有效,在实体正文中应答包括整个请求信息,具有"消息/http"的 内容-形式.这种方法的应答禁止缓存.
9.9 CONNECT（连接）
本说明中保留CONNECT方法用于能动态建立起隧道的代理服务器(例SSL 隧道[44]).
10.状态代码定义
每一段状态代码在下面被描述,包括他所能遵循的方法的描述和在应答中所必需的维护信息.
10.1 信息 1xx
状态代码的类简单描述了一个临时的回答,只是由状态行和可选择的报头所组成,并且由空行所决定,状态代码类没有所需的报头.自从HTTP/1.0没有定义任何1xx状态代码,在实验的条件下服务器严禁发送一个1xx应答给HTTP/1.0客户.
客户必须准备在接受通常应答之前接受一个或者多个1xx应答，甚至客户并不期待一个100状态的报文。不被期待出现的1xx状态应答也许会被用户端的代理所忽略。
代理服务器必须转寄1xx应答，除非代理服务器和客户之间的联系被切断，或者除非代理服务器本身请求1xx应答的发生。（举例说明如果一个代理服务器在它转寄一个请求时会加上一个"期望:100-----继续区域",它接下来就不需要转寄100回答应答）.
10．1．1 100 继续
客户应该和他自己的请求继续。中间的应答被用于告知客户请求的初始部分已经收到并且还没有被服务器所拒绝。客户应该继续发送剩下的请求，或者如果请求早已完成，那就忽略请求。服务器必须发送一个初始回答应答当请求完成时。如果想知道这部分状态代码用法及操作处理的详细讨论，那么请看8.2.3章节。
10．1．2 101转换协议
服务器了解并且愿意顺从客户的请求，经过升级的报文报头区域，为的就是一个应用协议的变化使之能够在连接中使用。服务器会转换协议使之成为那些通过应答升级报头的区域定义的立即在决定101应答的空行之后的协议。
协议应该仅仅在这样做有利的时候实行转换。比如，转换成为一个新版本的HTTP协议与老版本相比更加有利，转换成为一个实时同步的协议也许会有利,当被传送的资源需要利用这样的特征
10．2 成功 2xx
这种状态代码类简要的说明了客户的请求被成功的接收，理解，和接受
10.2.1 200 OK
请求已经成功。连同应答一起返回的信息是依赖于在请求中使用方法的。例如：
GET 与被请求的资源相应的实体在应答中一起发送。
HEAD 与被请求资源相对应的没有报文正文的报头区域在应答中发送。
POST 描述或者包含行动结果的实体。
TRACE 底端服务器已经接收的包含请求报文的实体
10.2.2 201 创建
请求已经完成同时导致新的资源被创造.新创造的资源和地址报头区域给出资源的最专业的URI可以被随应答实体返回的URI参考.应答应该包含用户或者用户代理可以从中选择出的一系列最最合适资源的特征和地址.实体的格式通过在内容形式报头区域给出的媒体形式来详细说明.最初的服务器必须在返回201状态代码以前创造资源.如果行动不能马上执行,服务器应该以202接受应答来应答它.
一个201应答可以由一个为了刚刚创造出的请求变量而显示出来的当前实体标记符的值的Etag应答报头区域,参见14.19节。.
10.2.3 202 接受.
为了处理,请求被接受,但是处理并没有完成.请求最终有可能或者不可能遵照行事,因为在处理过程实际发生时,它有可能被不允许.没有什么设备可以从如此的异步操作中重新发送状态代码
202应答是故意无委托的.它的目的就在于为了其他一些过程,在没有要求用户代理直到过程执行结束还坚持连接到服务器的情况下,允许服务器接受请求(也许是一批有所指向的一天只处理一次).实体和应答返回应该包括当前的请求状态,和或者一个指向状态监听器的指针或者关于什么时间用户期待请求完成的估计.
.
10.2.4 203 非权威信息
在实体报头中返回的维护信息并不是原服务器可用的最终的设置,但是他们是从一个本地的或是第三方的拷贝.提出的设置也许是原始版本的子集或是父集.举例来说,包括有关于也许导致被原服务器识别的维护信息的父集的本地注解信息.这种应答代码的用法并不必需,而且只有当应答为200时才适用.
10.2.5 204 没有内容
服务器完成请求并不需要返回实体的正文,并且也许想返回升级过的维护信息.应答也许包含新的或者是升级过的的实体报头形式的维护信息,如果这些当前的可以与请求的变量相关联.
如果客户是个用户代理,她就不应该改变它的文件观点以区别于那个导致请求被发送的文件观点.这样的应答主要是故意允许为了行动的输入发生在没有导致对用户代理主动的文件观点改变的情况下,尽管任何新的或者是升了级的维护信息应该是适应于用户代理现在的主动观点的.
204应答严禁包含报文正文,并且这样总是由在报头区域之后的第一个空行决定的.
10.2.6 205 重置内容
服务器已经完成了请求,用户代理应该重新设置导致请求被发送的文件观点.这种应答主要是故意允许输入行动通过用户输入发生,伴随而来的是对给出形式的清理为了让用户可以轻松开始另一个输入行动.应答严禁包含任何实体.
10.2.7 206 局部内容
服务器对于资源已经完成了部分GET请求.请求必须包含一个范围报头区域(14.35节),
指出了想要的范围,而且也有可能包含一个使请求条件化如果-范围报头区域
应答必须包含以下的报头区域:
或者是一个内容范围报头区域指出包含此现应答的范围,或者是对每个部分来说一个多部分的/字节范围的内容形式都包含内容范围报头.如果内容长度报头区域在当前应答中,那么它的值必须和实际在报文正文重传送的OCTET相匹配.
-日期
-Etag或者内容位置,如果能够在一个200应答中对于同一个请求发送报头.
-终止,缓存控制,和/或者变化,如果区域值与对于同一个变量以前发送的应答中的区域值不一样.
如果206应答是一个使用强缓存确认的的如果范围请求的结果,那么应答不应该包含其他实体报头. 如果应答是一个使用弱缓存确认的的如果范围请求的结果,那么应答严禁包含其他实体报头,这么做是为了防止缓存实体正文和升级报头之间的矛盾性.否则,应答必须包含所有对同一个请求返回的200应答中的实体报头.
如果Etag或者上次更改的报头不严格匹配,缓存严禁将一个206请求与其他以前缓存的内容连接起来
一个并不支持范围和内容范围的缓存严禁缓存206(部分)应答.
10.3 重新定向 3xx.
这种状态代码类指出了为了完成请求用户代理而所需要做的更进一步的行动.必需的行动 可以被没有与用户发生交互作用的用户代理执行并且在当且仅当在第二个请求中所需的方法是GET 或者是HEAD.客户应该侦察最终的重新定向环路,因为对于每一个重新定向来说这样的环路产生网络交通.
注解:老版本的规范推荐最大数量为5的重新定向.内容开发者应该知道也许有贯彻这样复杂限制的客户.
10.3.1 300 多样选择.
被请求的资源符合任何一套表示法之一,每种资源和她自己的特定地址,并且为了使用户可以选择一个首选的表示法和依照那个地址重新定向, 代理驱动的协商信息可以被提供出来.
除非它是一个HEAD请求,应答都应该有包含一系列用户或者用户代理可以从中选择的最最合适的资源特性和地址.实体格式被在内容形式报头区域给出的煤体形式详细说明.依靠用户代理的格式和容量,最最合适的那个选择有可能自动完成.不管怎样,这种规范并没有定义自动选择的标准.如果服务器有了一个陈述的首选,那么它应该包含为了关于那个陈述的特定的URI;用户代理为了自动重新定向可以使用地址区域值.除非指出另外的那么应答就可以缓存.
10.3.2 301 永久移动
被请求的资源已经分配了一个新的永久的URI,任何对资源的未来参考应该使用返回的URI中的一个.有编辑连接能力的客户应该对于被请求的URI从可能的服务器中返回的一个或者多个参考中实现自动连接参考.这种应答是可以缓存的除非它指出其他的.
新的永久的URI应该在应答中的地址区域给出.除非请求方法是HEAD,应答的实体应该包括一个段指向新的URI的超文本文本注解
如果301状态编码在对应于HEAD或者GEI方法中收到,用户代理严禁自动的重新定向请求除非它可以被用户确认,因为这样可能会改变请求发生的条件.
注解:当在接受到一个301状态编码后自动重新定向某一邮政请求,一些现存的HTTP/1.0用户代理将错误的将它改成GET方法.
10.3.3 302 创立
被请求的资源已经分配了一个新的永久的URI,任何对资源的未来参考应该使用返回的URI中的一个.有编辑连接能力的客户应该对于被请求的URI从可能的服务器中返回的一个或者多个参考中实现自动连接参考.这种应答是可以缓存的除非它指出其他的.
对临时的URI应该给予地址区域.除非请求的方法是HEAD,相应的实体应该包含一个短的指向一个新的URI的超级连接的超文本提示
如果302状态代码在一个应答非GEI或者HEAD请求中的过程中被接收到,那么用户代理严禁自动重新定位除非它可以被用户证实,因为它可能变化它的请求实现的条件.
注解: RFC 1945 和 RFC 2068 详细说明了客户不被允许改变在重新定位请求使用的方法.但是大多数存在的用户代理将302视为一个303应答, 不管最初的请求方法而在位置区域值实现一个GET方法.状态代码303和307被加在服务器上以希望它能够清楚客户所期待的那种反作用.
10.3.4 303 观察别的部分
对请求的应答可以在不同的URI中找到,并且应答应该在对资源的GET方法中重新得到.这种方法存在主要是为了允许邮政活性的输出脚本重新定向用户代理于一个选择的资源.新的URI不是一个最初请求资源的替代参考.303应答严禁缓存,但是对于第二个请求(重新定向)可以缓存.
不同的URI应该在相应的位置区域给出除非请求的方法是HEAD,相应的实体应该包含一个短的指向一个新的URI的超级连接的超文本提示.
注解: 许多HTTP/1.1以前的用户不理解303状态.当客户之间的协同工作能力被关注时,302状态代码也许会作为替代而使用,因为大多数用户代理就向这里描述的303那样反作用于302应答.
10.3.5 304 只读
如果客户提出一个条件的GET请求并且访问也已经允许,但是文档并没有修改,服务器应该应答这些状态编码.304应答严禁包含报文正文,并且总是由报头区域之后的第一个空行决定的.
应答必须包括以下报头区域:
-日期,除非数据亢长是14.18.1部分必须的.
如果一个无时钟原服务器遵守这些规则,并且代理服务器和客户将自己的日期加入任何成标准的应答中去,缓存会工作正常.
-Etag或者内容位置,如果能够在一个200应答中对于同一个请求发送报头.
-终止,缓存控制,和/或者变化,如果区域值与对于同一个变量以前发送的应答中的区域
值不一样.
如果条件化的GET使用了强的缓存??(请参阅13.3.3部分内容),那么应答中就不应该有其他实体报头.否则,应答中严禁包含其他实体报头,这样子保护了缓存实体正文和升级报头之间的矛盾性
如果304应答指出了当前尚未缓存的实体,那么缓存就必须忽视应答并且无条件的重复请求
如果缓存使用成为标准的204应答取胜疾缓存的入口,缓存就必须升级自己的入口以反映在应答中给出的任何新的区域值.
10.3.6 305 使用代理服务器
地址区域的被请求的资源必须通过代理服务器.地址区域给除了代理服务器的URI. 期望容纳者通过代理服务器重复这一单一请求.305应答必须由原服务器产生.
注解: RFC2068并不清晰于305有意于重新定向一个单一请求,并且此请求还只能由原服务器产生.不留心这些限制会产生相当严重的安全后果.
10.3.7 306(没有用的)
306状态编码在以前的规范中使用,现在已经不再用了,代码也保留了下来.
10.3.8 307临时重发.
请求的资源临时存在在另一个不同的URI下.由于重新定位有时可能变化,客户应该继续使用请求URI以备将来用途.这个应答只有当被缓存控制或是终止报头区域指出时才是可以存储的.
临时的URI应该在应答中的地址区域给出.除非请求的方法是HEAD,应答的实体应该包括一个短的指向一个新的URI的超文本提示, 许多HTTP/1.1以前的用户不理解307状态.因此,提示应该包括用户在新的URI中为了重复原始请求所必需的信息.
如果307状态代码作为应答不仅仅是GET或者HEAD等方法而接收,那么用户严禁重新定向请求除非它可以被用户确认,这也是可能的.
10.4 客户错误 4xx
状态代码4xx类是专门使用在客户看上去错误的情形下的.除非当应答一个HEAD请求时,服务器因该有一个包括错误情形的解释的实体,以及它是否一个临时或者终了的条件.这些状态编码可以应用于任何请求方法.用户代理应该向用户显示任何包括的实体.
如果客户在发送数据,使用TCP的服务器的实现应该小心以保证在服务器关掉了所有的输入连接时客户承认收到包含应答的包.在关掉之后如果客户继续发送数据给服务器,服务器TCP堆会发送一个重制包,也许这样子会在服务器开始被访问以及HTTP应用程序被解释的情况下,会擦掉客户不知道的输入缓冲.
10.4.1 400 坏请求
请求由于畸形的语法而不被服务器所理解.客户不应该重复自己的请求在没有改变的情况下.
10.4.2 401 未授权的
请求需要用户的鉴定.应答必需有用于对被请求资源的挑战的包含WWW鉴定报头区域.如有合适的认证报头区域,客户可以重复请求.如果请求已经包含了认证的信任书,那么401应答就指出了认证由于这些信任书而被拒绝.如果401应答包括和上一个应答同样的挑战并且用户代理已经尝试认证了至少一次,那么应该给用户在应答中给出的实体,因为实体中可能包含相应的诊断信息.HTTP访问认证在"HTTP Authentication: Basic and Digest Access Authentication" 中有所解释.
10.4.3 402 必需的支付
这种代码被保存下来以便将来使用.
10.4.4 403 禁用
服务器理解了请求,但是拒绝实现它.认证不会帮助,请求也不应该重复.如果请求的方法不是HEAD并且服务器愿意将请求为什么没有实现告诉大家,它应该在实体中描述拒绝的理由.如果服务器并不想将这条信息告诉客户,状态代码404(没找到)可以替代使用之.
10.4.5 404 没有找到
服务器并没有找到任何可以匹配请求URI.条件是永久的还是暂时的也没有任何的迹象.410状态编码应该在服务器知道老的资源是永远不可以得到的并且没有以前的地址的情况下,通过一些内在的可配置的机构,才应该使用.这种状态编码当服务器不想精确展示为什么请求被拒绝或者何时没有其他的应答可以利用的时候被广泛的应用.
10.4.6 405 不被允许的方法
在请求行中特殊指定的方法不允许访问由请求URI指定的资源.应答必需有一个包括一些对于被请求的资源有效的方法的允许报头.
10.4.7 406 不接受
请求指定的资源只可能产生依照在发送请求中的接受报头有不接受的内容特性的应答实体.
除非它是一个HEAD请求,应答应该有包括一系列可兹利用的实体特性和位置,从中用户和用户代理可以找出最最适合的.实体的格式由在内同形式报头区域给出的媒体形式所指定.依靠此格式和用户代理的性能,最佳的选择可能自动的完成.然而,这中规范并没有定义任何针对此自动选择的标准
注解: HTTP/1.1服务器允许返回依照在请求中发送的接受报头不被接受的应答.在某些情况下,发送一个406应答甚至更加有利.用户代理被鼓励去检查输入应答的报头以判断是否可以接受.
如果应答不被接受,那么用户代理应该暂时停止接收更多数据并且向用户查询是否需要更进一步的行动决定.
10.4.8 407 代理服务器认证所必需
这种代码很相近于401,但是它指出了客户必须和代理服务器之间认证自己.代理服务器必需返回一个代理服务器----认证报头区域,该区域包括是为了被请求的资源而用于代理服务器的挑战.客户可能随着一个合适的代理服务器认证报头区域一起重复它的请求. HTTP访问认证在" HTTP Authentication: Basic and Digest Access Authentication"中有解释.
10.4.9 408 请求超时
在服务器准备等待的时间段内,客户并没有产生请求.客户也许会在以后的任意一时间内重复请求.
10.4.10 409 冲突
由于与资源的现在状态的冲突请求游客能不能完成.代码只有在用户被期待有可能解决冲突和提交请求的地方的情况下允许使用.应答体应该包括对于用户认识冲突来源的足够多的信息.理想的,应答体应该有对于用户和用户代理可以解决问题的足够多的信息量.然而,这也许是不可能的或者是不必需的.
冲突通常会发生在应答PUT请求的时候.例如,版本正在被使用而且正在PUT的实体有和以前请求(第三方)冲突的资源的变更的话,服务器会使用409应答来指出它不能完成请求.在这种情形下,应答实体可能会包括一系列在内容形式应答中定义的两种版本的区别之处.
10.4.11 410 停止
服务器上的被请求的资源不再可用,而且不知道以前的地址.我们期望此条件被认为是永远的.有连接编辑能力的客户在用户同意的情况下,应该删掉对请求URI的参考.如果服务器并不知道,或者没有设备去决定是否条件是永久的,状态代码404(未找到)此时应该使用.这种应答是不可被缓存的除非另外指出.
410应答主要是通过通告请求者资源有意不可获得和服务器主人希望那些远方连接到资源的连接都被请除掉这两条信息用于援助WEB维护.这样的事情很普通发生在时间受限,增加的服务和不再服务器端工作的的属于私人性质的资源这些情况下.我们并不需要标注所有的永久不可用的资源"没了"或是标注上任意一段长度的时间-----这些交给那些服务器的主人自己去判断吧.
10.4.12 411 必需的长度
服务器拒绝接受没有定义的内容长度的请求. 如果加上了一个有效的"包含有请求报文正文中的长度"的内容长度报头区域,那么客户可能重复请求.
10.4.13 412 预处理失败
在一个或者多个请求中给出的预处理在被服务器验证的时候会被评价为错误的.这种应答代码允许客户将预处理放在当前资源维护信息(报头区域数据),并且这样作以防止有其他的适应资源请求的法的而非所要的那一个.
10.4.14 413 请求实体太大
服务器拒绝处理一个请求因为请求比服务器所能和所愿处理的还要大.服务器可能关掉连接以防止客户继续请求.
如果条件是暂时的,服务器应该有一个重新试-在之后报头区域以便于指出这是暂时的在什么时间以后客户可以再试一次.
10.4.15 414 请求的URI过长
服务器拒绝请求的服务因为请求的URI比服务器所愿意解释的要长.这种比较珍稀的条件之可能发生在党课互补恰当的将POST请求变为有长查询信息的GET请求的情况下,或是客户落到了一个重新定向的URI黑洞中时,再或者是在一些使用固定长度缓冲区用以读或者处理请求的URI的服务器遭到钻安全漏洞的黑客的攻击的时候.
10.4.16 415 不被支持的媒体类型
服务器拒绝提供服务给请求因为请求的实体所请求的方法是在一种不被请求资源支持的格式下.
10.4.17 416 请求范围不满足
如果请求包括范围请求报头区域,或者是在区域内没有范围说明符的值溢出当前选择资源的延伸,再或者是请求没有包含如果--范围请求--报头区域,服务器应该返回连同状态代码的一个应答.(对于字节-范围,它意味着所有的字节范围说明中的第一字节???的值比当前选择资源的长度要大)
当状态代码返回一个字节范围请求时,应答应该包含一个详细说明选择资源的长度的内容范围区域.(请参阅14.16).应答严禁使用多部分/字节范围的内容形式.
10.4.18 417 期望失败
在请求报头区域给出的预料不可能被服务器实现,或者,如果服务器是代理服务器,服务器有请求不可能被下一个??服务器实现的模糊的证据
10.5 服务器错误 5xx
应答状态代码用阿拉伯数字"5"表示服务器知道它自己有错误或者自己不能实现请求等这些情况.除了当应答一个HEAD请求,服务器应该有一个包括错误形式的解释的实体和它是否暂时或者永久的条件的解释的实体.用户代理应该显示任何包括的实体给用户.这些应答代码对于任何请求的方法都是适用的.
10.5.1 500 服务器内部错误
服务器遇到预料到的防止它完成请求的情况.
10.5.2 501 不能实现
服务器不支持完成请求所必需的功能性. 当服务器并不认识请求的方法并且没有能力对于任何资源支持时,这是合适的应答
10.5.3 502 坏网关
服务器,当被用作一个网关或者是代理服务器时,就会从上流的服务器收到无效的应答以试图完成请求的访问.
10.5.4 503 难以获得的服务.
由于暂时的过载或者服务器维护,服务器此时不能处置请求.这说明了这是一个暂时的条件过一些耽搁会减轻.如果知道,耽搁的长度应会在重新试-在之后报头中指出.如果没有重新试-在之后给出,客户应该处理处置应答就像处理一个500应答一样。
注解：503状态代码的存在并不暗示着服务器必需使用它当它变得过载时。有些服务器只想简单的拒绝连接。
10.5.5 504 网关超时
服务器,当被用作是网关或者是代理服务器时, 由于URI指定的上游服务器或者其他一些辅助服务器以有资格尝试完成请求,并没有收到及时的应答.
注解:设备注解:一些展开的代理服务器都知道返回400或者500当DNS查找时间过长时.
10.5.6 505 HTTP版本不支持
服务器并不支持,或者拒绝支持,在请求信息中用到了HTTP协议版本.服务器指出它不能或是不愿完成使用与客户端一样的版本的请求,就像在章节3.1中描述的那样,???????.应答应该包含描述为什么那个版本不为支持而为什么其他协议被服务器支持的实体..
11.入口验证
HTTP提供了一些可以选择的用于服务器挑战用户请求和用户提供验证信息的的挑战-应答验证机制.入口验证的大体框架,和基础及分类验证的规范在" HTTP 规范:"基础及分类入口验证"中详细说明.这份说明从规范中采用了"挑战"和"外交国书"的定义
12.内容谈判
大多数HTTP应答都有一个包括人类用户解释信息的实体.自然地,相对于请求它需要提供给用户"最佳利用"的实体.很不幸的是,对于服务器和存储器来说,不是所有的用户都有同样的关于"什么是最好的"的判断准则,并且并不是所有的用户代理有相同的解释实体形式的能力.为此,HTTP为了"内容谈判"提供了一些机制-----当有很多种可能的表示时如何选择对于一个请求的最佳的表示.
注解: 这不是所谓的"格式谈判,因为变化的表现也许是相同的媒体形式,但是使用那种型号的不同性能的,还也许是使用了不同的语言.
任何包含一个实体正文的的应答都有可能受配于谈判,甚至包括那些错误的应答.
在HTTP中有两种可能的内容谈判:服务器驱动的和代理驱动的谈判.这两种谈判是相互正交的,这样他们可以单独或者混合使用.混合使用的一种被称为透明的谈判的方法,发生在当缓存使用由最初的为了后来的请求而提供服务器驱动谈判的服务器提供的代理驱动谈判信息时.
12.1 服务器驱动谈判
如果对于一个请求的最佳表示的选择由服务器提供的运算法则来完成,我们就叫它是服务器驱动谈判.选择是基于应答中可行的解释和在请求报文的特定报头区域的内容或是其他一些适合请求的信息(如客户的网络地址).
服务器驱动在从所有可行的表示法中挑选最佳的运算法则对于客户很难描述时是有利的,或者是当服务器要求将它的"最佳估计"和第一应答一起送给客户端时有利.为了提高服务器的估计能力,用户代理可以包含为了这样一个应答描述自己参数选择的请求报头区域.
服务器驱动谈判有这些缺点:
1. 对于任何用户来说决定什么是最佳的实际上是不可能的,因为那样需要有关于用户代理能力和应答所想要发挥的用途的所有完整的信息.
2. 让用户代理在每一个请求中描述自己的能力也是很低效的并且对于用户的隐私也是潜在的威胁.
3. 它复杂了原服务器的实现和相对于请求的运算法则.
4.它可能会限制一个公共缓存的能力,因为缓存对于不同的请求将使用同样的应答.
HTTP/1.1 包含以下通过描述用户代理的性能和用户的参数选择使服务器驱动谈判成为可能的请求报头区域: 接受(章节14.1),???(章节14.2),接受编码(14.3),接受语言(14.4),以及用户代理(14.43).然而,原服务器并不受限于这些尺寸,并且可能会基于请求的各各方面而变化不同的应答,包括在请求报头区域之外的信息或者在此规范中没有定义的扩展报头区域.
不同的报头区域可以用作表达
服务器用作选择服从服务器驱动谈判的表示法的变量.请查阅章节13.6关于缓存中不同报头区域的用法和章节14.44关于服务器不同报头区域的用法.
12.2 代理驱动谈判
在代理驱动谈判中,对于一个应答的最佳表示法的选择是在代理从原服务器端收到最初的应答后实现的.选择是基于一系列可用的应答的通过自己URI鉴定的表示法,其中包括初应答的报头区域和实体正文.从表示法中的选择可以自动实现(如果用户有能力这么做)或者人工的用户从产生的菜单(可能是超文本)中选择.
代理驱动的谈判,当应答有可能不同于普通使用的尺寸时或者是原服务器不能够从检查请求中决定用户代理的性能时,并且一般说来当公共的缓存被用作分散服务器负载和减少网络用法.
代理驱动的谈判也有需要二次请求以获得最佳替换表示法这样一个缺点.只有当缓存在使用时二次应答才有效.作为补充,规范中并没有定义支持自动选择的任何机制,虽然它也没有阻止任何机制被发展如像在HTTP/1.1中的扩展那样.
在当服务器不愿或是不能提供不同的使用服务器驱动谈判的应答时,HTTP/1.1定义了300(多种选择)和406(不接受)这两种状态编码以使代理驱动谈判成为可能.
12.3 透明的判断
透明的判断是服务器驱动和代理驱动谈判的结合体.当缓存被供给了一系列可兹利用的应答的表示法并且变量的尺寸被缓存充分理解时,缓存可以执行代表为了资源的后来请求的原服务器服务器驱动的判断.
透明的谈判有分散这样的优点, 否则是原服务器必需的谈判工作,以及当缓存可以正确估计应答时可去除用户代理二次请求的沿时.
此规范没有定义任何关于透明判断的机制,虽然它也没有像在HTTP/1.1中使用的扩展那样阻止发展机制.
13 HTTP中的缓存
HTTP典型应用于能通过采用缓存技术而提高性能的分布式信息系统。HTTP/1.1协议包括的许多元素都尽可能的进行缓存操作。因为这些元素与协议的其他方面有着千丝万缕的联系，而且他们相互作用、影响。因此，独立于算法、报头、响应代码等的细节描述来讲述HTTP中缓存的基本设计是大有裨益的。
如果不对缓存技术做明显改善，他将一无用处。HTTP/1.1中缓存的目的是降低在众多情况下发送请求的需要，同时降低在其他情况下发送完整响应的需要。前者使众多操作中往返流程减少，我们用"过期" 机制来达到这一目的（见13.2节）；后者使网络带宽需求降低，我们用"认证"机制来达到这一目的（见13.3节）。
对性能,可用性和分离操作的需要要求我们能放宽语义透明度的要求.HTTP1.1协议允许源服务器,缓存和代理客户在必要时明确降低透明度.然而,因为不透明操作会迷惑不专业的用户,而且可能同某些服务器应用不兼容(如).在下列情况下,协议需要透明度被降低:
仅当代理或源服务器提出明确的协议层次的放宽请求.
仅当缓存或代理向终端用户提出明确的放宽警告.
因此,HTTP1.1协议满足如下要素:
1.当各部分都提出要求时,协议提供完全的语义透明度.
2.协议允许源服务器或用户代理明确请求且控制不透明操作.
3.协议允许缓存对未达到要求的语义透明度的响应发出警告.
说明:服务器,缓存,或代理设备可能面临的设计决策不在本说明书讨论范围之内.如果有关于语义透明度的决策,此设备应尽力保持语义透明度除非有仔细而完整的分析表明破坏透明度将有重大好处.
13.1.1缓存 正确性
在如下列情况下,一个正确的缓存必须从他所存储的内容中选出最新者来响应请求. (参见13.2.5,13.2.6,13.12节)
1. 经过检验,源服务器对收到响应重新确认生效返回的结果与原来相同.（参见13.3节）
2．."足够保鲜"(参见13.2节).在缺省值情况下,它表示对代理,源服务器和缓存
的最低的保鲜性要求(参见14.9节);如果源服务器详细说明,那么保鲜性要求仅是对源服务器本身而言有效.如果某一存储的响应对代理和源服务器的最低保鲜要求仍不满足,慎重考虑,缓存应返回响应并加入适当警告报头(参见13.1.5,14.46节),除非这种响应是被禁止的(参见14.9节).
3. 304(未修改),305(代理人重寄),或 错误(4xx,5xx)响应信息.
如果缓存无法与源服务器通信,则当响应能正确的从缓存发出时,缓存应
如上响应;如果不能,则缓存应发出错误或警告信息以说明存在通信故障.
如果缓存收到响应(不论是一个完整响应还是一个304响应),它会将其转寄
给请求客户,当收到的响应被刷新时,缓存应该转寄给请求客户而不须加入新的警告
信息(且无需去掉已经存在的警告报头).缓存不能仅仅因为某一响应在传送过程中
"过时"了而令响应重新生效,这将引入一个死循环.一个用户代理收到没有警告的过
时响应应对用户显示警告.
13.1.2 警告信息
当缓存器返回响应既不是第一手的也不是最保鲜(fresh)的,此响应必须附加警告,
使用一般警告报头.此警告报头信息和刚刚定义的警告在14.46中有详述,此警告允许
客户采取适当行动.
警告信息可以被用作他途,不论是否与缓存有关.警告的使用,而非错误状
态代码区分了前述响应和实际错误.
警告信息由三类阿拉伯数字代码表示.第一个数字表明当重发成功后警告信
息是否必须或必须不被删除.
See section 14.46 for the definitions of the codes themselves.
1xx 这是描述响应刷新或重发状态的警告信息,因此在重发成后功必须被删除掉
1xx警告信息仅当确认一个缓存实体时才由缓存器产生.它不能由代理端产生.
2xx 一个描述实体内容或报头的警告信息,它不因重新确认而被矫正,而且在成功的
重新确认后也不能被删除.
代码定义见14.46
HTTP1.0 缓存器存储响应中的所有警告信息,且不会删除第一类警告.
传给HTTP1.0的警告信息带有一个附加的警告数据区,它阻碍了未来的HTTP1.1兼
容错误缓存警告.
警告信息也传送一个警告文本.此文本可以使用任何自然语言,而且可以
随意选择准用的字符.
响应可以附加多重警告,包括属于同一类代号的警告.例如,服务器可能
提供同样的错误而文本包括英语和巴斯克语两种.
当响应附加了多重警告信息时,把所有的信息都显示给用户是不合理的
也是不现实的.此版本的HTTP并未指定严格规定警告显示的优先权和顺序,但却
给出了一些提示.
13.1.3 缓存控制机制
在HTTP1.1协议中的基本缓存机制是隐含指示给缓存器.在某些情况下,
一服务器或代理可能需要给缓存器以明确的指示,我们用缓存器控制报头来达到
这一目的.
缓存器控制报头允许代理或服务器传送多种指示,既可以是请求,也可
以是响应.这些指示代替缺省的缓存算法.作为一般规律,当出现明显的报头内
容冲突时,最根本的协调办法是实用性原则(即为,选择能最好保持予以透明度
的报头),可是,在某些情况下,缓存控制指示明显的削弱了语义透明度.
缓存器控制指示详述于14.9节
13.1.4直接的用户代理警告
很多用户代理允许用户覆盖基本缓存机制.例如，用户代理可能允许用户
指定缓存实体是无效的。或者，用户代理还可能习惯于加上缓存控制：对任何请
求最大值=3600。用户代理不应该默许非透明的行为或造成明显低效率的行为，但
可以由用户的明确行动来外在配置。
如果用户已经覆盖了基本缓存机制，用户代理应向用户明确指出，一旦
此改变作用于信息显示，可能与透明度要求发生冲突。协议通常允许用户代理来
决定响应是否已经失效，当实际发生时，该指示需要单独显示。该指示不必是对
话框，它可以是一个图标。
如果用户对缓存机制的覆盖使缓存器效率反常降低，用户代理应连续的
将这一状态提示给用户以防止用户无意中占用了额外资源或面临过长的延迟。
13.1.5 规则和警告的例外情况
在某些情况下，缓存操作员会选择设置缓存当用户未提出请求时发出过时
的响应。这一决定不应草率作出，但有时为了提高性能，尤其当缓存与源服务器
不良连接时，又是必须的。一旦缓存器返回一个失效的响应，这一定标明（使用
警告报头）令代理端软件生效来警告用户，可能存在潜在的问题。
协议还允许用户代理采取措施来获得第一手的或最新的响应。因此，
如果用户代理明确请求第一手的或最新的，缓存器不能返回过时响应，除非由于
技术上或政策上的原因而无法实现。
13.1.6 由客户控制的行为
当源服务器是满期信息的最初来源，在某些情况下，客户将需要控制
缓存器决定是否回复缓存的响应而不使其生效。客户需要使用缓存器控制报头的
几项指示来作此工作。
一个客户的请求可以指定它能接受的未确认响应的最长时限；指定一个
零点控制确认所有响应。一客户还可以指定响应期满前的最小时限。所有这些操
作增强了对缓存行为的控制，所以将不能放宽缓存器的语义透明度。
一客户也可以指定它接受失效响应，直到达到最大值。这放松了对缓存
器的控制，也就可能与源服务器对语义透明度的限制发生冲突。但对不良连接
时支持分离操作和提高性能来说又是必须的。
13.2 过期(Expiration)模型
13.2.1 服务器指定模型
当缓存器能完全避免向源服务器发送请求时，它工作于最佳状态。
避免请求的根本机制是源服务器给出一个明确的未来过期时间，这样响应信
息或许可以满足后来的请求。换句话说，缓存器不必首先联系服务器就能回复
一个最新响应。
我们期望服务器能指定一个对响应的明确预期过期时间，以确保在到达期
限之前，实体没有发生变化。当过期时间仔细选择时，这通常可以保持语义透明度。
此过期机制仅应用于缓存器作出的响应，而不针对直接传递给请求客户的
第一手响应。
如果一源服务器要强制一个语义透明的缓存器来确认每一个请求，它可
以指定一个明确的已过去过期时间。这表明响应总是失时效的，因此缓存器应在用
其答复后来的请求之前确认之。（见14.9.4）
如果源服务器想强制HTTP1.1缓存器无论如何配置都确认每条请求,则应
该使用"必须再确认"缓存器控制指示.(见14.9)
服务器指定明确的过期时间既可以使用过期报头,也可以使用最大期限(Max_age)
报头.
过期时间不能用来强制用户代理刷新其显示或重载其资源；它只应用于缓
存机制，当一个对某资源的新请求发出时，此机制仅须检测该资源的过期状态。
（见13.13）
13.2.2 启发式过期
由于源服务器并不总是提供明确的过期时间,HTTP缓存器典型设置为启发
式过期时间,采取使用其他报头值的算法来估计一个近似的过期时间。HTTP1.1说明
书中并未给出详细算法，但却利用最坏情况来限制其结果。由于启发式过期次数可
能影响语义透明度，故应慎重使用，而且我们鼓励源服务器提供尽可能大的过期
次数。
13.2.3 年龄(Age)计算
为了解缓存实体是否为最新，缓存器需要知道其年龄是否已超过保鲜时
限。我们在13.2.4节中讨论如何计算后者，本节讨论如何计算响应或缓存实体的
年龄。
在此讨论中我们用“NOW”来表示“主机进行计算时时钟的当前值”。
使用HTTP协议的主机，除了运行源服务器和缓存器的主机，应当使用NTP[28]
或其他类似协议来将其时钟同步到一个全球性的精确时间标准上来。
HTTP1.1协议要求源服务器尽可能在发送每条响应时都附加一个日期
报头来标明此响应产生的时间.(见14.18)我们用"日期值"这一短语来表示日期报
头的值----一种适于算术操作的形式.
当从缓存获得响应消息时,HTTP1.1用年龄响应报头来传达其年龄信息.
年龄值是缓存器估计的源服务器生成或重新确认响应的时间值.
本质上,年龄值是响应信息在从源服务器开始的所有缓存器驻留的时间
加上其在网络路径上传输的时间.
我们用年龄值（"age_value"）来标明年龄报头的值----一种适于算术操作的表示方法.
一个人的年龄可以通过两种完全独立的途径来计算:
1.如果本地时钟与源服务器时钟同步的相当好,则用"NOW"-日期值,若结果
为负,则取零.
2.如果从源服务器开始的所有缓存器均执行HTTP1.1则就取年龄值（age_value）.
如上我们有两种方法计算响应的年龄,我们合并二者如下:
矫正后接收到的年龄值=MAX(NOW-DATA_VALUE,AGE_VALUE)
而且无论那种方法都能得到可靠的结果.
由于网络附加延时,一些重要时隙会在服务器产生响应和下一个缓存器或客
户收到它之间被忽略.如果不经修订,这一延迟会带来不正常的低年龄.
corrected_initial_age = corrected_received_age
+ (now - request_time)
因为导致返回年龄值的请求一定在年龄值的产生之前就发出了，我们可以
通过记录请求发出的时间来矫正网络附加延时。则当收到一个年龄值时，它必将被
认为与发出请求的时间有关，而不是收到响应的时间。这将保证不论经历多少延时，
其表现都是稳定的。
当缓存收到响应时的算法摘要：
/*
* age_value
* is the value of Age: header received by the cache with
* this response.
* date_value
* is the value of the origin server's Date: header
* request_time
* is the (local) time when the cache made the request
* that resulted in this cached response
* response_time
* is the (local) time when the cache received the
* response
* now
* is the current (local) time
*/
apparent_age = max(0, response_time - date_value);
corrected_received_age = max(apparent_age, age_value);
response_delay = response_time - request_time;
corrected_initial_age = corrected_received_age + response_delay;
resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;
以上段落英文更明白一些。
缓存实体的当前年龄是从缓存实体最后被服务器确认的时间（以秒记）
加上校正初始年龄。当缓存实体产生一条响应，它必须包含一个年龄报头区：与缓
存实体当前年龄一样的值。
响应中存在年龄报头区意味着这不是第一手响应。但反之未必，因为那仅
当所有缓存器均使用HTTP1.1时才成立。
13.2.4 过期计算：
为了确定一条响应是新是旧，我们需要将其保鲜期限和年龄进行比较，年龄的计算见13。2。3节，本节讲解怎样计算保鲜期限，以及一条响应是否已经被排出。在下面的讨论中，数值可以用任何适于算术操作的形式表示。
我们用“过期数值”（"expires_value"）来标明过期报头，我们用“最大年龄值”来标明缓存控制报头的秒数。（question?）
最大年龄在过期之前指示，所以一旦响应中出现最大年龄，计算将变得非常简单。
freshness_lifetime = max_age_value
否则，若缓存中出现“Expires”，计算如下：
freshness_lifetime = expires_value - date_value
注意上述运算不受时钟误差影响，因为所有信息均来自源服务器。
如果 Expires, 缓存控制: max-age, 或 缓存控制: s-maxage (见 14.9.3) 均未在响应中出现,且响应对缓存没有其他限制， 缓存可以用启发式算法计算freshness lifetime。缓存器必须对年龄大于24小时又不带警告的响应附加113号警告。
而且，如果响应有最后修改时间，启发式过期值应不大于时间片。典型设置为片断的10%
计算响应是否过期非常简单：
response_is_fresh = (freshness_lifetime > current_age)
13.2.5 澄清过期值
由于过期值不是严格制定的，所以可能两个缓存器对相同资源制定的刷新值不同。
如果客户对一个在其缓存中以刷新的请求作出一个恢复的非第一手响应，而且缓存实体中的日期值比响应中的新。，则客户可以忽略此响应。如果这样，将要求“缓存控制”：max-age=0 来强迫检查源服务器。
如果缓存器有两个描述相同而确认器不同的响应，它必须使用有最近日期报头的那个。
13.2.6 澄清多重响应
因为客户可能收到经多重路径来的响应，所以有些响应流经一簇缓存器，而另一些响应流经另一簇缓存器，客户收到响应的顺序可能与源服务器发响应的顺序不同，我们希望客户能选用最新的响应。
实体标签和过期值都不能影响响应顺序，晚一点的响应可能带有早的过期时间。日期值的精度也只有一秒。
当缓存器要重新确认一个缓存实体，而且受到响应的日期报头晚于已存在的实体，则客户应无条件的重复请求。
Cache-Control: max-age=0
强制任何中间缓存器确认它们的副本。
Cache-Control: no-cache
或者强制它们从源服务器获取一个新的副本。
如果日期值相同，可以使用任何一个响应。
13.3 确认模式
当缓存器想要用一个失时效的条目来相应客户的请求,他首先必须向源
服务器(如果可能则向一中间缓存器)检验这一缓存条目是否仍然可用.我们称之为
"确认"缓存条目.由于我们不想当缓存条目为可用时必须为再传送整条响应而付出
代价,而且不想当缓存条目不可用时也必须多传一圈,HTTP1.1协议支持使用条件反应方法.
协议支持条件响应方法的关键特征围绕"缓存确认器"展开.当源服务器
生成一个完整响应时,它同时传送一类确认器一直伴随着缓存条目.当一客户(用户
代理或代理缓存器)对含有缓存条目的资源做出条件请求时,他同时在请求中包含有相互关联的确认器.
服务器则核对此确认器和当前确认器,如果他们匹配(见13.3.3),则返回
一个特定状态码(通常为304)且不含条目内容.否则,返回整个响应(包含条目内容)
这样,我们避免了在确认器匹配时传送整条响应,同时也避免了在不匹配时往返传输.
在HTTP1.1协议中,一个条件请求除了带有特别的报头(包含确认器)来暗中
的将它转入条件算法以外,和普通报头没有差别.
协议中包括缓存确认机制的主动和被动两种状态.具体说来,请求可以在
当且仅当又匹配确认时执行,也可以在当且仅当没有匹配确认时执行.
说明:没有确认器的响应也可以缓冲存储且接受服务直至被排出,除非这是
被缓存控制指令明确禁止的.可是,如果没有确认器,则缓存不能有条件的恢复它,这表明无法刷新除非被排出.
13.3.1 最后修改日期 (Last-Modified Dates)
最后修改报头值经常被用作确认器.简言之,一缓存条目在最后修改期后
未经修改则被认为是有效的.
13.3.2 标签缓存确认器(Entity Tag Cache Validators)
标签响应报头值,一个实体标签,提供了一个"模糊"缓存确认器.这将允许
在不便存储修改信息的情况下进行可靠的确认,包括HTTP日期数据不充足和源服
务器不想因使用修改日期而带来麻烦的情况.
实体标签描述见3.11节,有关其报头的描述见14.19,14.24,14.26,14.44.
13.3.3 强,弱确认器
由于源服务器和缓存器会比较两个确认器来确定他们是否代表相同的条目,所以通常希望实体发生任何变化,确认器也相应变化,这样的确认器为强确认器.
同时还会有这样的情况,服务器倾向于仅在发生重要的语义变化时才改变确认器.在资源变化时确认器未必变化的称为弱确认器.
实体标签通常是强确认,但协议提供一种机制来标志弱 Copyright www.cnpaf.net (2007). All Rights Reserved.
确认.可以认为,强确认在实体的每一字节变化时均变化,而弱确认仅在实体含义变化时才变化,强确认是某一特定实体的标志,而弱确认是某一类同义实体的标志.
注: 强确认的例子:一个整数,他随着每次实体发生变化而定值增长.
一个实体的修改时间(以秒计算)可以作为弱确认器,因为实体可能在一秒内变化两次.
对弱确认的支持是可选的.支持弱确认可带来等价体的高效缓存.
当客户生成一个在确认报头中包含确认器的请求或服务器进行比较时均要用到确认器.
强确认可在任何情况下使用,而弱确认仅在不依赖严格相等时才可用.
客户可以发出简单GET请求,伴随强,弱确认器均可.客户在发其他请求时,不能用弱确认.
HTTP1.1协议定义确认的唯一功能是比较.有两种比较功能,这依赖于是否允许弱确认.
-- 为了同等考虑,两确认器必须完全一样且均非弱确认.
-- 两确认器必须完全相同,且至少有一个被标明为"弱".
除非被明确标清,实体标签是强的.
最后修改时间被用作请求的确认器时默认为弱的,除非从下列规则导出强的结论.
确认器不会在一秒内变化两次.
或者
-确认器可能被用户用于If-Modified-Since 或者 If-Unmodified-Since报头。
-此缓存实体包含一日期值，他给出源服务器发出响应的时间。
-最后修改时间至少比日期值早六十秒。
或者
-确认器已经被中间缓存器同缓存实体比较过
-此缓存实体包含日期值，给出源服务器发出响应的时间。
-最后修改时间至少比日期值早六十秒。
此种方法基于以下事实:如果两条响应在同一秒内被发出但有相同的最后修改时间,则至少有一条响应日期值和最后修改时间是相同的.
如果客户在仅有最后修改时间没有模糊确认器的情况下执行子范围修复,
则仅当最后修改时间是强确认时才可以.
若缓存器或源服务器收到一个条件请求,而不是完整GET响应,则必须使用强比较函数.
此规定允许HTTP1.1协议下,缓存器和客户可以对从HTTP1.0中得到的值安全的进行子域恢复.
13.3.4 关于何时使用实体标签和最后修改时间的规则
我们对源服务器，客户和缓存器采用一套规则和建议来规定在何时，出
于何种目的，应采用何种确认器。
HTTP/1.1 源服务器：
-应该发送一实体标签除非它做不到。
-可以发送弱实体标签如果其满足性能要求或不能发送强确认。
换句话说，对http1.1服务器来说,比较好的做法是同时发送强实体标签和最后修改值.
说明:为保证语义透明缓存,服务器必须避免两个不同实体重复利用同一
强实体标签值或者两类不同语义的实体重复使用同一弱实体标签值.
HTTP/1.1 客户：
-若服务器用实体标签,则必须对任何缓存条件请求都使用此实体标签.
-仅当服务器提供最后修改值时,它应该在非子域条件请求中使用该值.
-仅当HTTP1.0服务器提供了最后修改值时,他可以在子域缓存条件请求
中使用该值.
-若两者均被提供,则两者均应使用.
当一服务器收到的请求既包括最后修改时间也包括一个或多个实体标签,
则它一定不能发出304代码,除非这是协调好的.
当一个HTTP1.1缓存代理收到上述请求时,一定不能返回一个本地缓存响
应给客户,除非它对所有请求都是一致的.
说明:一般规律是传送尽量多的非冗余信息.
HTTP1.0客户和缓存器忽略实体标签.
13.3.5 不确认条件
其他报头的比较不被用于确认缓存实体.
13.4 缓存能力响应
除非被明确限制,缓存系统可以将一成功的响应作为缓存实体一直存储,如果它是保鲜的可以不确认而返回它,如果成功确认,也可以返回它.
说明:某些HTTP1.0缓存器可能违反这一条而不提示警告.
还有,某些情况下可能不便保留一实体,或将其返回给后续请求.
注意14.8节防止共享缓存存储和回复一个早先的包含授权报头的请求.
包含状态码200,203,206,300,301或410的响应可能会被用于回复后面的响应.
带有其他一些状态码的响应不能用于回复后面的请求,除非有明确的缓存控制
或其他报头允许之.
13.5 从缓存器构造响应
缓存器的目的是存储响应请求的信息来响应后面的请求.再很多情况下,缓
存器仅返回响应的适当部分给请求者.如果缓存器保有一个基于前面请求的实体,它
可能必须将其与新响应合并.
13.5.1 端到端和Hop-by-hop报头
为定义缓存器行为,我们将报头分成两类:
端到端报头和hop_by_hop报头（仅对简单的传输层连接有意义，不被缓存，
也不被代理服务器向前传递）
hop-by-hop 报头:
- Connection 连接
- Keep-Alive 保活
- Proxy-Authenticate 代理人鉴别
- Proxy-Authorization 代理人授权
- TE
- Trailers 轨迹
- Transfer-Encoding 传输编码
- Upgrade 升级
所有其他均为端到端报头
13.5.2 不可更改报头
HTTP1.1的某些特征,如分类鉴定,基于某一端到端报头值.一透明代理不能
修改端到端报头除非报头要求或明确许可.
传输代理不能修改下列各项，如果他们不存在，也不能添加。
- Contents location
目录区
- Content-MD5
- ETag
- Last-Modified
最后修改时间
- Expires
但它可以添加这些区域.如果排除报头被添加,则必须赋值来标明次响应的
日期报头.
包括不变形缓存控制指示或有请求.
- Content-Encoding
内容编码
- Content-Range
内容区
- Content-Type
内容类型
警告:对端到端报头的不必要修改可能导致在今后高版本协议引入更强的鉴
定机制后鉴定失败
内容长度区的去留规则见4.4节.
13.5.3 联合报头（Combining Headers）
但缓存向服务器发出确认请求,若服务器回复304或206响应,则缓存器构
造响应回复给请求客户.
若状态码为304,则缓存器使用缓存实体的报文构造响应,若状态码为206
且标签和最后修改时间恰好匹配,则缓存器可以将存储的和刚收到的实体和并作为