新响应的报文(见 13.5.4).
缓存实体中的端到端报头用于构造响应,排除以下内容:
-1xx警告报头被删除
-2xx保留
-304或206响应中的报头代替缓存实体中的相应部分。
除非要删除缓存实体，缓存器必须用收到的响应报头取代端到端报头。换句话说，
接收到的端到端报头覆盖缓存实体中已有的端到端报头。
注意：此规则允许源服务器用304或206响应来刷新缓存器中的相应实体。
13.5.4 联合字节范围
一条响应可能仅传送一条正文的一部分，经过几次这种传送，一缓存器可能会
收到同一条正文的好几部分。
如果缓存器已经收到正文的一部分，且又收到了另一部分，缓存器可以
将新收到的内容与已有内容合并，当所有收到的响应及缓存实体含有强确认时。
13.6 缓存谈判响应
使用服务器驱动内容转让(见12.1),由响应中的变化报头区说明, 改变了缓存器能用响应回复后续请求的条件和过程.(服务器使用变化报头区见14.44)
服务器要用变化报头区告知缓存器在众多可缓存响应类型用什么样的请求
报头区来用服务器驱动转让.变化区命名此类报头区为"选择"请求报头.
当缓存器收到指定一个或 Copyright www.cnpaf.net (2007). All Rights Reserved.
更多包含变化报头区的缓存实体的后续请求,缓存器不能用这样的缓存实体来构造新请求的响应,除非新请求中所有选中的请求报头与初始请求相应部分匹配.
当且仅当两个请求中的选择请求报头可以从前一请求变形为后一请求时称为匹配.变形指,在相应的BNF允许的位置增加或删除LWS,或者按照4.2节中的消息报头规则合并合并同名的多个消息报头区.
一个变化报头区数值"*"一般不能匹配而且对该资源的后续请求,服务器只能粗略解释.
如果旧的请求报头不能匹配新的,缓存器不能用相应缓存实体来回复响应
除非它第一个将请求发给服务器且服务器回复304,包括实体标签或内容地址说明
实体可用.
如果一实体标签用于标志缓存的代表,向前传递的请求应该是条件的且包
括实体标签.这给服务器揭示了缓存器刚刚缓存的所有实体,所以如果其中任何实体与请求实体匹配,服务器可以用304响应中的ETag报头区来稿置缓存实体可达.如果新请求中的实体标签与已存在实体匹配,则新响应应该用于刷新存在实体的报头区, 并将结果返回给客户.
如果任何已存在缓存实体仅包括相关实体的部分内容,它的实体标签不能
包含于If-None-Match报头区中, 除非此请求是对一个被该实体完全满足的区域.
如果缓存器收到一个成功响应,已存在实体不能回复将来的响应且应该被删除.
13.7 共享和非共享缓存
出于安全和保密考虑，有必要区分共享和非共享缓存。非共享缓存是仅
供一个用户使用的缓存器，此种情况下，可用性由适当的安全机制控制。其它缓
存器均被认为是共享缓存。此协议的其它部分给出了其它的一些限制以防止隐私
的丢失和可达控制的失败。
13.8 错误和不完全响应缓存行为
缓存器收到不完整响应时也可以存储它，但是必须把它看作部分响应。
部分相应可以合并（见13.5.4）;合并结果可能是完整的或仍是部分的.缓存器
不能把部分相应回复给客户,除非有明确要求.
如果缓存器在试图重新确认一实体时收到5xx响应，它既可以将其传送给
客户也可以认为服务器响应失败。后一种情况，它可以回复一个以前接收到的响应
除非缓存实体明确要求“必须确认”
13.9 GET 和 HEAD 的副作用：
除非服务器明确禁止缓存它们的响应，对任何资源应用GET和HEAD算法，
如果响应曲子缓存器，都不会引起能导致错误的副作用。他们确实有副作用，但
缓存器在决定缓存时不必考虑。缓存器总是“看源服务器的脸色行事”。
一个例外：有些应用习惯于在query URLs时使用GET和HEAD，从而带来显著的副作用，
缓存器不能认为对他们的响应是刷新的，除非服务器明确给出过期时间。这说明不能
从缓存器取出HTTP1.0服务器对URIs的响应。
13.10 刷新或删除后的无效性
某些算法对源服务器资源的操作将使一个或多个已存在的缓存实体不可
用，即为，虽然他们还是“新鲜”的，但却不能准确反映源服务器想回复给请求
的信息。
HTTP协议无法保证所有此类实体均被标明无效。例如，引起源服务器变
化的请求可能没到达存贮缓存实体的代理服务器，但是，有一些规则帮助减少类
似的错误。
本节中，“使一个实体失效”表示缓存器或者删除该实体的所有instances，或者标明其为不可用，而且在重新用于回复后面的响应前必须有重新确认命令。
某些HTTP算法必将导致缓存器使一个实体失效。这是实体被URI请求或内
容区域报头提到。这些算法是:
- PUT
- DELETE
- POST
为了防止服务器拒绝处理，基于URI或内容区域报头的失效处理仅当主机
部分与URI请求相同时才进行。
缓存器向它不理解的算法传递请求时令所有被URI请求指明的实体失效。
13.11 强制写通过（ Write-Through）
所有可能对源服务器资源进行修改的算法都要写给源服务器。这通常包括
所有算法除了GET和HEAD。缓存在将此种请求转给内地服务器并获得相应答复前不
能对请求客户做出响应。
相反情况（write-back）在HTTP1.1中是不允许的，这是由于提供一致更新
非常困难且服务器缓存和网络的故障比“write-back”早。
13.12 缓存替换
如果收到一个新的响应，它的同源响应均已被缓存，缓存器就要用新响应
回复当前请求，且将其插入缓存器存储区，并用其回复所有被退回的旧响应。
说明：一个日期报头比已存响应旧的新响应是不可缓存的。
13.13 历史纪录
用户代理经常使用历史体制来重新获得以前的实体。
历史机制和缓存是不同的，尤其历史对资源的当前状态是不透明的，更准
确地说就是历史纪录明示用户在获得资源时看到了什么。
默认情况，过期时间不用在历史机制中。若实体仍然在存，即使它过期
历史机制仍可以显示它，除非用户明确提出要代理刷新过期纪录。
这并不能解释为禁止历史体制告诉用户事情已经过时。
说明：如果历史纪录未必阻止用户看过时资源，这将强制服务提供者避免
使用HTTP过期控制和缓存控制。
14 报头域定义
本节定义了所有HTTP/1.1种标准头域的语法和语义。对于实体头域，发送者和接收者指的是客户端和服务器，它是由实体的发送和接收者来定义的。
14．1接受（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 ) ]
星号字符用作将媒体形式聚集成为一个范围."*/*"指出了所有的媒体形式,"type/
*"指出了某种形式的图表类形.媒体范围可能包含适用于那个范围的媒体形式参数.
每个媒体范围可能跟随着一个或者多个接受-参数.开始为字母"q"的参数指出相关
质量的因素.任何一个开头字母为"q"将媒体范围参量和接受参量区分开来.质量要
因素允许用户或者是用户代理使用从零到一的值来指出对于此媒体形式来说喜欢
的相关程度,缺省时q的值是1.
注释:q参数名字可以用来将媒体形式从接受扩展参量中分辨出来,这是由于以前的
练习.虽然这保护了任何任何首字母为q的参量被煤体范围一起使用,这样的事件被
认为不太可能在LANA注册中被给与缺少的"q"参量或者在Accept中任何媒体形式的
珍稀用法.未来的媒体形式从注册和"q"参量中气馁了.
例子:
Accept: audio/*; q=0.2, audio/basic
该例应该被解释作"我喜欢audio/basic,但是如果在质量中€标记向下之后是最佳
可利用的话,就给我发送任何音频形式.如果当前没有接受报头区域,那么可以认为
是客户接受了所有的媒体形式.如果当前有 Copyright www.cnpaf.net (2007). All Rights Reserved.
接受报头区域并且如果服务器不能发送
根据组合接受区域的值可以接受的响应的话,那么服务器应该发送一个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实
体."
媒体范围可以不被更多特定媒体范围或者特定媒体形式考虑.如果多余一个的媒体
范围适用于一个给出的形式的话,那么最最特定的参考优先.比如"Accept: text
/*, text/html, text/html;level=1, */*"就有以下的优先:
1) text/html;leve=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
注释:一个用户代理可能会被提供一套默认的针对于特定媒体范围的值.然而,除非
用户代理是个关闭的系统并且不可以和其他翻译代理相互作用,这套缺省可以由用
户自己来配置.
14．2 接受-字符集（Accept-Charset）
接受-字符集请求报头区域可以用来指出什么特性装置可以为响应所接受.这个区域允许有能力理解更复杂或者是特定目的特性的装置的客户通知给在那些特性装置中有能力描述文档的服务器服务器是否具有上述所述的能力.
Accept-Charset = "Accept-Charset" ":"
1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
特性装置的值在3.4章节中描述.每一个??可以分配一个表示用户对??喜爱程度的相关联质量的值.缺升值是q=1.一个例子是:
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
特殊的值"*",如果在接受-??区域显示的话,则可以与每一个并没有在接受??中其他
什么地方提起的特性装置相匹配.如果没有'*'在当前接受-??区域,那么所有没有明
确提出的特性装置都回得到一个为零的质量值,除去在相同情况下可以得到1的
iso-8859-1.如果没有接受-??报头在当前,那么缺省设置就是任何特性装置都是可
接受的.如果当前存在接受-??报头并且服务器不能发送根据接受-??报头可以接受
的响应的话,那么服务器就会发送一个错误响应和406状态代码,在不可接受响应在
发送过程中时也是允许的,
14．3 接收编码(Accept-Encoding)
接收编码(Accept-Encoding)请求报头域和接收(Accept)相似,但限定响应中可接收的内容码(content-codings)(3.5节).
Accept-Encoding = "Accept-Encoding" ":"
1#( codings [ ";" "q" "=" qvalue ] )
codings = ( content-coding | "*" )
Examples of its use are:
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)是否可接受的服务器采用这些规则:
如果内容码(content-coding)是接收编码(Accept-Encoding)域中列出的一系列内容码(content-codings)中的一种,则它是可接受的,除非它跟着 a qvalue of 0.(定义在3.9节, a qvalue of 0.意思是不可接受的)
接收编码(Accept-Encoding)域中的特殊符号”*”匹配任何报头域中没有明确列出的可利用的内容码(content-coding).
如果多种内容码(content-codings)是可接受的,则具有最高非零qvalue的内容码(content-codings)是优先的.
"identity"内容码(content-codings)总是可接受的,除非特定的说明其是不可接受的,因为接收编码(Accept-Encoding)域包括"identity;q=0"或者因为域中包括"*;q=0"和不明确的包括"identity"内容编码.如果接收编码域的值为空,则只有"identity"编码是可接收的.
如果接收编码域出现在请求中,且根据接收编码报头服务器不能发送可接收的响应,则服务器应当发送带有406(Not Acceptable)状态码的出错响应.
如果请求中没有接收编码域,服务器可以假定客户机将接收任意的内容编码.在这种情况下,如果"identity"是可利用的内容编码之一,则服务器应该采用"identity"内容编码,除非有额外的信息说明别的内容编码对客户机更有用.
注意:如果请求中没有包括接收编码域,且"identity"内容码是不可利用的,则能被HTTP/1.0客户机解读(i.e."gzip" and "compress")的内容码一般是优先的.当发送别的内容码是,一些老的客户机显示不正确的信息.服务器也许会以关于用户代理或客户机的信息为基础做出决定.
注意:大多数HTTP/1.0应用程序不承认或遵守域内容码相关的qvalues.这意味着qvalues将不工作或被x-gzip or x-compress允许.
14．4 认可术语
The Accept-Language request-header field is similar to Accept, but
restricts the set of natural languages that are preferred as a
response to the request. Language tags are defined in section 3.10.
认可术语请求报头区与认可是相近的，但规定了一套自然语言用来响应请求.术语
标识在3.10节说明.
Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] )
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
每个语言范围均被赋以一个品质因数,它代表用户用这种语言的钟爱程度.品质因
数默认值为一.例如:
认可语言: da, en-gb;q=0.8, en;q=0.7
表示:我喜欢丹麦语,但也接受不列颠英语和其它种英语.一种语言范围对应一
种术语标识如果它正好等于标识,或者如果它正好等于标识的前缀,例如第一个跟
在前缀后面的标识符是'-'.特殊范围"*",如果在认可术语区中出现，对应所有标
识符。
说明：使用前缀匹配规则并不表示如果用户理解一戴又标识的术语，他就也理解
所有代前缀标识的术语。
认可术语区指定给语言标识的语言品质因数是匹配标识的最大语言范围
的品质数值。如果在此区内没有语言范围匹配此标识，则品质因数制定为0。如果
请求中没有认可术语报头，服务器应假设所有语言被等同接受。如够出现了认可
术语报头，则所有品质因数大于0的语言均是可接受的。
在每个请求中发送认可术语报头说明可接受语言与保护用户隐私识背道而
驰的，对此问题的专门讨论见15.1.4
鉴于可理解性高度依赖于个别用户,推荐客户应用用户理解的语言.如果
选择用户不理解的,则请求中不能加入认可术语报头区.
说明:当选择用户可接受语言时,我们提醒实现者如下事实,用户并不熟悉术语匹
配的细节,所以应给出适当提示.
14．5接收范围(Accept-Range)
接收范围(Accept-Range)响应报头域允许服务器给出对资源请求的接收范围:
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
acceptable-ranges = 1#range-unit | "none"
接收byte-range请求的源服务器可以发送
Accept-Ranges: bytes
但没必要那样做.客户机可以产生byte-range请求,即使是它没有收到相关的报头域.
Range units定义在3.12节.
不接收任何种类对资源的范围(range)请求的服务器可以发送
Accept-Ranges: none
来建议客户机不要尝试范围(range)请求.
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)实体报头域中列出了由 Copyright www.cnpaf.net (2007). All Rights Reserved.
请求指定资源支持的几种方法--URI。这一报头域的目的严格限于通知接收者与资源相联系的方法有哪些。允许报头域必须出现在405（方法不被允许）应答中。
允许="允许""：" #方法
使用示例：
允许: GET, HEAD, PUT
这一报头域不能阻止用户使用其他方法。然而允许域给出的指示应予以执行。由原服务器在处理每一请求时定义允许的方法集。
允许域可由PUT请求提供，以建议新资源支持某些方法。服务器不必一定支持这些方法，且应在允许域中给出实际支持的方法。
因为用户有其他与原服务器通信的渠道，故代理服务器即便不理解域中指明的所有方法，也不得修改允许报头域
14．8 授权（Authorization）
用户代理往往希望服务器自我验证,但在收到401响应后则没有必要了.用户代理通过包括Authorization请求报头域的请求那样做. Authorization请求报头域的值由包含用户代理验证信息的信任状所组成,这些用户代理处于请求资源的领域.
Authorization = "Authorization" ":" credentials
HTTP Authentication中描述了HTTP访问的身份鉴定: Basic and Digest Access Authentication" [43].假如请求在特定的领域中通过了验证,则同样的信任状对该领域内所有其它请求都是有效的(假定验证方案本身不需要,否则信任状依照亟待解决的问题或用同步时钟而不同)
当共享的高速缓冲存储器(看13.7节)接收具有验证(Authorization)域的请求时,必须返回相应的响应作为其他请求的应答,除非是接下来的特殊情况之一.
如果响应包括s-maxage缓存控制指示信息,高速缓存可以用响应来应答并发的请求.但(如果已超过了特定的最大生存期)代理服务器的高速缓存首先必须重新生效,用来自新请求的请求报头允许源服务器验证新的请求.(这是为s-maxage定义的行为.)假如响应包括"s-maxage=0",代理服务器必须在重新利用之前使之生效.
如果响应包括must-revalidate缓存控制指示信息,高速缓存可用响应来应答并发请求.但如果响应失去时效,所有缓存首先必须使它重新生效河源服务器一致,用来自新请求的请求报头允许源服务器验证新的请求.
假如响应包括public缓存控制指示信息,它可以被返回来应答并发请求.
14．9 缓存-控制（Cache-control）
缓存-控制通用-报头域用于标明请求/应答链上所有缓存机制必须遵守的指令。这些指令规定了一些意在预防缓存对请求或应答造成不良影响的行为。它们通常覆盖了缺省的缓存算法。 缓存指令是单方向的，因为请求中指令的存在并不意味着应答中也会有同样的指令。
请注意HTTP/1。0缓存机可能并不实现缓存-控制，而是只实现
Pragma:无-缓存（参见14。31节）。
代理服务器或网关的应用程序必须不顾缓存指令对其本身的意义，毫无例外的让它们通过，因为这些指令可能对请求/应答链上的所有接收者都适用。
缓存-控制="缓存-控制""：" 1#缓存-指令
缓存-指令="缓存-请求-指令|缓存-应答-指令
缓存-请求-指令=
"无-缓存" ; 14.9.1节
| "无-存储" ; 14.9.2节
| "最大-时限""=" delta-秒 ; 14.9.3, 14.9.4节
| "最大-陈旧" ["="delta-秒] ; 14.9.3节
| "最小-保鲜"["="] delta-秒 ; 14.9.3节
| "不传输" ; 14.9.5节
| "仅当缓存时" ; 14.9.4节
| 缓存-扩展 ; 14.9.6节
缓存-应答-指令=
"公共" ; 14。9。1节
|"私有"["="<"" 1#域名〈"〉]; 14。9。1节 |"无缓存" ["="<"" 1#域名〈"〉]； 14。9。1节
|"不存储" 14。9。2节
|"不传输" 14。9。5节
|"必须经重新确定有效" 14。9。4节
|"代理服务器重新确定有效" 14。9。4节
|"最大时限""="delta-秒 14。9。3节
|"s-最大时限""="delta-秒 14。9。3节
|缓存-扩展 14。9。6节
当指令不伴有1#域名参数出现时，该指令适用于整个请求或应答。
当指令伴有1#域名参数出现时，它仅适用于被命名的域，而不适于请求或应答的其他部分。这一机制支持可扩展性；HTTP协议将来的版本可以通过将指令应用于HTTP/1。1中未定义的域来实现。
缓存-控制指令 可分为如下几类：
-- 对可缓存的范围的限制；这可能只由原服务器指定。
-- 对缓存内容的限制；这可由原服务器或用户代理指定。
-- 对基本过期无效机制的改进；这可由原服务器或用户代理指定。
-- 对缓存重新确认有效及重载的控制；这可能仅由用户代理指定。
-- 对实体传输的控制
-- 缓存系统的扩展。
14．9．1 何谓可缓存的
缺省情况下，若请求方法，请求报头域和应答状态指明了应答为可缓存的，则它就是可以缓存的。 13。4节总结了这些可缓存性的缺省情况。 下列缓存-控制应答指令允许原服务器覆盖缺省的应答的可缓存性：
公共
指明应答可被任意高速缓存机缓存，即便在该应答通常是不可缓存的或只可由不共享的高速缓存机缓存的情况下也是如此。（参见14。8节，关于认证的附加详述）
私有
表明应答报文的所有部分都是为单一用户准备的且不得被共享缓存机缓存。
这使原服务器可以申明应答的特定部分是针对单一用户的，对其他用户的请求而言并非有效应答。 私有（不共享）缓存可以缓存应答。
注：私有一词仅用来控制应答在何处可被缓存， 而不能保证报文内容的私有性。
不缓存
若指令"不缓存"没有指定域名，则缓存机不得应答那些未经原服务器重新确认有效的后继的请求。
这使得原服务器即便对设置为回送陈旧应答给客户请求的高速缓存机也能防止缓存。
若指令"不缓存"确实指定了一个或多个域名，则高速缓存机可以在其他的缓存要求限制下应答后继请求。 然而，指定的域名不得在用于应答那些未经原服务器重新确认有效的后继请求。这使得原服务器防止了应答中某些报头域重复使用，同时又允许缓存应答的剩余部分。
注：大多数HTTP/1。0高速缓存机不会认出或遵守这一指令。
14．9．2 哪些可被高速缓存机保存
不保存
"不保存"指令的目的在于防止无意中泄露或滞留了敏感信息（比如存在备用磁带上了）。
"不保存"指令适用于整个报文，可在请求或 Copyright www.cnpaf.net (2007). All Rights Reserved.
应答中发送。 若由请求方发送，则高速缓存机不得保存该请求或其应答的任何部分。若由应答方发送，高速缓存机不得保存该应答和相应请求的任何部分。该指令对非共享与共享高速缓存机都适用。 "不得保存"在这里意味着缓存机不得有意地将信息保存在非易逝存储器上，且必须尽最大努力将信息在转发后尽快从易逝存储器上转移。
即使这一指令是与应答相联系的，用户也可能明言要在缓存系统之外保存该应答（比如通过"另存为"对话框）。 历史缓存区可作为例行公事保存这些应答。
这一指令地目的在于满足某些在意信息经未知渠道偶然泄漏到缓存数据区的用户与服务程序作者提出的要求。虽然这一指令的使用可能改善了保密性，但值得提醒的是，它又绝非保证保密性的充分的或可靠的机制。
14．9．3 对基本过期失效机制的改进
实体的过期时间可由原服务器的"过期"报头（参见14。21节）指定。 或者，它也可由应答中的"最大-年龄"指令说明。当被缓存的应答含有"最大-年龄"缓存-控制指令时，应答若现有年龄大于出现对同一资源的新请求中所给年龄值（以秒为单位）则被视为陈旧。应答中的"最大-年龄"指令意味着该应答是可缓存的（如，"公共"），除非存在其他更严格的缓存指令。
若应答同时含有过期报头与"最大-年龄"指令，最大-年龄指令覆盖过期报头，即便过期报头中的描述更严格也不例外。这一规则使原服务器可就给定应答为HTTP/1。1（或更新的版本）缓存机提供比HTTP/1。0缓存机更长的过期时间。这在某一HTTP/1。0缓存机出于诸如类似同步时钟的原因错算了年龄或过期时间的情况下可能有用。
许多HTTP/1。0缓存机会按照与缓存-控制应答指令"不缓存"等价的方式来处理小于或等于应答日期值的过期值。若HTTP/1。1缓存机接到这种应答，且应答不含缓存-控制报头域，则它应视应答为不可缓存，从而保持与HTTP/1。0服务器的兼容性。
注：在兼有不懂新特性的旧版缓存机的网络上，一台原服务器可能愿意采用较新的HTTP缓存控制功能，如"私有"指令。这样，原服务器就需要将新特性与其值小于等于日期值的过期报头域结合起来。这将防止旧版缓存机误缓存应答。
s-最大年龄
若应答包含s-最大年龄指令，则对共享缓存机（而非私有缓存机）而言，由该指令指定的最大年龄覆盖其他最大年龄指令或过期报头的指定。 S-最大年龄指令也暗示了代理服务器-重新确定有效指令的句法（参见14。9。4节），也就是说，在首先经原服务器重新确认为有效之前，共享缓存机不得用那些变得陈旧了的目录来应答后继请求。 私有高速缓存机忽略此s-最大年龄指令。
请注意，大多数与此规范不相适的旧版缓存机并不执行任何缓存-控制指令。 想要使用缓存-控制指令来限制而非避免遵守HTTP/1。1的缓存机进行缓存得原服务器可以利用最大-年龄指令覆盖过期报头的条件以及早于HTTP/1。1的缓存机不检查最大-年龄指令这一事实。
其他指令允许用户代理修改基本过期失效机制。 这些指令可由请求指定：
最大-年龄
表明客户机愿接受其年龄不大于指定时间（以秒计算）的应答。除非也含"最大-陈旧"指令，否则客户机不愿接受陈旧应答。
最小-保鲜
表明客户机愿接受其保鲜寿命不小于现有年龄与指定时间之和（以秒计算）的应答。也就是说，客户机想要一至少在一定时间内保持保鲜的应答。
最大-陈旧
表明客户机愿接受已经过期的应答。 若指定最大-陈旧为某值，则客户机愿接受过期时间不超过给定秒数的应答。若未指定最大-陈旧的值，则客户机愿接受任意年龄的陈旧应答。
若缓存机或出于请求的最大-陈旧指令，或出于缓存机被设置为覆盖应答过期时间的原因，最终返回了一个陈旧的应答，缓存机都必须在旧应答上添加一警告报头，采用警告110（应答是陈旧的）。
高速缓存机可被设置成不经确认就返回陈旧应答，但这不应与任何"必须"等级的关于缓存重确认的要求（如"必须-重新确认有效"缓存-控制指令）冲突。
若新请求与缓存的条目均包括"最大-年龄"指令，则取两者间较小值来决定该请求的缓存条目的保鲜程度。
14．9．4 缓存重新确认有效和重载控制
有时用户代理可能希望或出于需要坚持让 Copyright www.cnpaf.net (2007). All Rights Reserved.
缓存机与原服务器之间重新确认缓存条目的有效性（而不只是通向原服务器的传输路径中的下一高速缓存机），或是从原服务器处重载缓存条目。端到端的重新确认有效手续在缓存机或原服务器高估了缓存应答的过期时间时可能需要。端到端重载在缓存条目由于某些原因被侵蚀时可能需要。
如果客户机没有自己的本地缓存拷贝，即所谓"未指明的端到端重新确认有效"，或客户机没有本地的缓存拷贝，即所谓"经指明的端到端重新确认有效"， 都有可能要求端到端的重新确认有效。
客户机可用缓存-控制请求指令来指明三种行动中的一种：
端到端重载
请求包括"不缓存"缓存-控制指令，或是与HTTP/1。0客户机兼容的"Pragma:不缓存"。
请求的"不缓存"指令中不得含有域名。服务器应答这种请求时不得使用缓存的拷贝。
经指明的端到端重新确认有效
请求包括"最大-年龄=0"缓存-控制指令，从而迫使通向原服务器路径上的每一高速缓存机都与下一缓存机或服务器之间重新确认自身条目的有效性。初始请求包括由客户机现有的确认模块决定的缓存有效性确认过程。
未指明的端到端重新确认有效
请求包括"最大-年龄=0"缓存-控制指令，从而迫使通向原服务器路径上的每一高速缓存机都与下一缓存机或服务器之间重新确认自身条目的有效性。初始请求中不包括缓存条件有效性确认过程。沿途第一个含有此资源缓存条目缓存机（如果存在的话）包括决定于现有的有效性确认模块的缓存-有效性确认。
最大-年龄
当中转缓存机被"最大-年龄=0"的指令迫使重新确认其缓存条目有效性，且客户机在请求中提供了自己的有效性确认器时，所供的有效性确认器可能不同于缓存条目中现存的有效性确认模块。在这一情况下，缓存机可以在不影响句法透明性的前提下将其中的任一有效性确认模块用于自己的请求。
然而，对有效性确认器的选择可能影响性能。 最好的方法是让中转缓存机采用自己的有效性确认模块来构造请求。若服务器应答以304（未经修改），则缓存机可以将自己的确认后拷 Copyright www.cnpaf.net (2007). All Rights Reserved.
贝连同200（OK）应答一起发回给客户机。但若服务器发回新的实体和有效性确认器，则中转缓存机可使用强比较函数比较返回的有效性确认器与客户机请求中提供的有效性确认器。若客户机的有效性确认器与原服务器的一致，则中转缓存机仅需发送回304（未经修改）。 否则，它就发回新的实体和200（OK）应答。
若请求含有"不缓存"指令，则它不得包括最小-保鲜，最大-陈旧或最大-年龄指令。
仅当经缓存时
在某些情况下，如网络连接极为糟糕时，客户机可能想要缓存机只返回它现存的应答，而不要与原服务器之间进行重载或重新确认有效性。为实现这一点，客户机可以在请求中包括"仅当经缓存时"指令。若它收到这一指令，缓存机应该应答以符合请求其他限制的缓存条目，或是应答以504（网关超时）状态。 然而，当一组缓存机是作为呢部内部联系良好的同一系统来操作的话，这样的请求可能会在那组缓存机内部转发。
必须-重新确认有效性
由于缓存机可能被设置为忽略服务器指定的过期时间，且客户机请求可能包括最大-陈旧指令（与前者效用相似），协议还包括了一种由原服务器要求后继使用中重新确认缓存条目有效性的机制。
当缓存机接到的应答中有必须-重新确认有效性指令时， 该缓存机不得在条目变得陈旧后不经与原服务器重新确认有效性就用来应答后继请求。（也就是说， 若仅由原服务器的"过期"报头或"最大-年龄"取值确定缓存的应答已陈旧，缓存机就每次都必须执行端到端有效性重新确认。）
"必须重新确认有效性"指令对支持某些协议特性可靠运作是必要的。在所有情况下，HTTP/1。1缓存机必须遵守"必须重新确认有效性"指令；特别是，若缓存机出于任何原因无法到达原服务器，则它必须产生504（网关超时）应答。
当且仅当对实体的请求的有效性重确认的失败会导致错误的操作（比如未申明但未被执行的最终事务）时，服务器应该发送"必须重新确认有效性"指令。 接收者不得采取任何违背该指令的自动行动，也不得在重确认失败时自动提供未经确认的实体拷贝。
虽不提倡如此，但受到严格的连接限制的用户代理还是可以违背这一指令，但在这么做的同时必须明确警告用户提供的是未经有效性确认的应答。每一未确认的访问都必须伴有警告，且应要求明确的用户许可。
代理服务器-重新确认有效性
除了不适于非共享用户代理缓存机之外， "代理服务器-重新确认有效性"指令与"必须重新确认有效性"指令含义相同。 它可用于对经认证的请求的应答，以允许用户的缓存机保存应答，并在稍后无须重新确认就返回应答（因为它已经被该用户认证了），同时仍然要求服务于多个用户的代理每次都重新确认有效性（从而确保每一用户都通过认证）。 请注意这种经认证的应答还需要"公共"缓存-控制指令，使得它们可以被缓存。
14．9．5 不得转换指令
不得转换
中转缓存机（代理服务器）的实现者们发现转换某些实体正文的媒体类型是很有用的。 比如，一台非透明的代理服务器可以在图象格式之间进行转换，以节省缓存空间或减少慢速链路上的数据通信量。
然而，当这些转换应用于某些应用的实体正文时，会引发严重的操作方面的问题。比如，医学图象应用，科学数据分析和端到端认证都依赖于接收到与原实体正文一比特都不差的实体正文。
所以，如果报文包括了"不得转换"指令， 中转缓存机或代理服务器就不得改变13。5。2节中列出的受"不得转换"指令影响的报头。这意味着缓存机或代理服务器不得改变由这些报头定义的实体正文的任何方面，包括实体正文值本身。
14．9．6 缓存控制扩展
缓存-控制报头域可通过一个或多个缓存-扩展标志的使用来实现扩展。其中每一标志都赋予一可选的值。 信息性的扩展（那些无须改变缓存机行为的）可以不经改变其他指令的句法而添加。
行为性扩展被设计为现有基本缓存指令的修正。 新指令与标准指令都有提供，于是不理解新指令的应用程序会缺省地按采用标准指令规定的行为，而理解新指令的应用程序则将其认作标准指令提出的要求的修正。这样，缓存-控制指令可以无须改变基本协议就得到扩展。
这一扩展机制依赖于HTTP缓存机对所有初始HTTP版本中缓存-控制指令和某些扩展方式的遵守，以及对所有它不理解的指令的忽略。
例如，考虑一个假想中的名为"共同体"的新应答指令，作为"私有"这里指令的修正。我们定义这个新的指令以表明除了非共享缓存机之外，任何只可被同一共同体成员共享的缓存机都可以缓存此应答。原服务器若想允许UCI共同体在它们的共享缓存机之间使用本来是私有的应答，只需在该应答中添入：
缓存-控制：私有， 共同体="UCI"
见到这一报头域的缓存机即便不理解"共同体"缓存-扩展也能正确操作，因为它还见到并理解"私有"指令，就会按缺省的安全方式行事。
未经认出的缓存-指令必须被忽略；按照假定，任何可能未被HTTP/1。1高速缓存机认出的缓存-指令都与标准指令（或应答的缺省可缓存性）相结合使用，从而是缓存机的行为即便在它不理解扩展指令时也尽可能保持正确。
14．10 连接
连接这一概括报头域允许发送者指定某一特定连接中的选项设置，且不得由代理服务器在以后的连接中传送。
连接报头遵循如下语法：
连接="连接""：" 1#（连接-标志）
连接-标志=标志
HTTP/1。1代理服务器必须在转发报文之前即解析连接报头域，针对域中每一连接-标志，从报文中移开所有与连接-标志同名的报头域。 连接选项是由连接报头域中的连接-标志指明的，而非任何附加的报头域，因为这些附加报头在缺少与连接选项相关的参数时无法被传送。
连接报头中列出的报文报头不得含有诸如缓存-控制之类的端到端报头。
HTTP/1。1定义了"close"选项，以供发送者宣布连接在完成应答后将被关闭。例如
连接：close
无论是出现在请求或应答的报头域中，都表明连接不应被视为在完成现有请求/应答后是"持续的"（参见8。1节）。
不支持持续连接的HTTP/1。1应用程序必须在每一报文中都添上"close"连接选项。
接收到含有连接报头的HTTP/1。0（或更低版本）报文的系统必须为每一连接-标志都去除或忽略报文中与之同名的报头域。这样做避免了早于HTTP/1。1版本的代理服务器误转发这些报头域。
14．11 内容编码
"内容编码"实体报头域是作为媒体类型的修正。此域存在时，其值表明对实体正文采用了何种附加的内容编码，从而须采用何种解码机制以获取"内容类型"报头域中指出的媒体类型。"内容编码"的主要目的是使文件可以在不丧失其基本媒体类型身份的同时被压缩。
内容编码="内容编码" "：" 1#内容译码
内容译码由3。5节定义。其应用示例为：
内容编码：gzip
内容译码是由请求定义（URI）的实体特性。通常，实体正文以编码方式存储，只在翻译或类似使用前才解码。然而，非透明代理服务器在确知新译码可被接受者认可的情况下可能会改变内容译码，除非报文中含有"不得转换"的缓存控制谓词。
若实体的内容译码不具备同一性，则应答必须包含列有所用非同一内容译码的内容编码实体报头（14。11节）。
若请求报文中的实体内容编码对原服务器而言不可接受，则服务器应以415（不被支持的媒体类型）状态码应答。
若实体采用多种编码，则内容译码应按它们的使用顺序列出。
关于编码参数的其他信息和由未被此说明定义的实体报头域给出。
14．12 内容语言
内容语言实体报头域描述了实体面向的受众的使用语言。请注意，这不一定等同于实体正文中用到的所有语言。
实体语言="实体语言""："1#语言标记
语言标记由3。10节定义。内容语言的主要目的在于让用户根据自己喜用的语言确认并区别众实体。由是，若正文内容只是针对懂荷兰语的人的话，相应的域应为：
内容语言：da
若未指明内容语言，缺省值为内容针对所有语种的受众。这既可能指发送者认为内容与任意自然语言无关，也可能指发送者不知此内容应面向何种语言。
要面向多种听众，可列出多种语言。例如，同时用毛里土语和英语发行的"Waitangi之约"就可以用：
内容语言：mi,en
然而，实体中有多个语种并不代表它一定是为多语种的观众准备的。比如"初学拉丁文"之类的语言启蒙教程，显然是针对英语观众的。这里，恰当的"内容语言"应只包括"en"。
内容语言可用于任意媒体类型 -- 它不限于文本式文件。
14．13 内容长度
内容长度实体报头域按十进制或八位字节数指明了发给接收者的实体正文的大小，或是在使用HEAD方法的情况下，指明若请求为GET时将发送实体正文的大小。
内容长度="内容长度""："1*DIGIT
示例：
内容长度：3495
除非按4。4节的规则被禁用，应用程序应使用此域指明报文正文的传输长度。
任何不小于零的内容长度均为有效值。 4。4节描述了如何在未知内容长度时测定报文长度的方法。
请注意此域的含义域MIME中的相应定义迥异。MIME中，它是"报文/扩展正文"内容类型的可选域；在HTTP中，除非按4。4节的规则被禁用，一旦报文长度在传送前被确定，就应发送此域。
14．14 内容位置
内容位置可用来在从一独立于请求资源的URI的位置访问实体时提供报文中实体的资源位置。服务器应根据应答实体为此变量提供一内容位置；尤其是在资源和多个实体相联系，而这些实体各享独立位置，可被分别访问时，服务器应为特定的返回变量提供内容位置。
内容位置="内容位置""："（绝对URI|相对URI）
内容位置的值也决定了实体的基础URI。
内容位置值并非原请求URI的替代；它只是申明了请求中对应特定实体的资源位置。
此后的请求若想确定特定实体的来源，可以指定内容位置URI为请求的URI。
缓冲存储机不能以为若实体的内容位置URI异于访问URI就可用此实体来应答那一内容位置URI下的后续请求。但如13。6节所述，内容位置可用于区分从同一请求资源得到的多个实体。
若内容位置是相对URI，则此相对URI是相对于请求URI来解释的。
PUT或POST请求中内容位置报头的含义未定；服务器可自由忽略。
14．15 内容-MD5
如RFC 1864[23]中所定义的，内容-MD5实体报头域是实体正文的MD5摘要，以期提供端到端的实体正文的报文完整性检验（MIC）。（注：MIC有利于检测实体正文传送中的偶发改动，但不一定能防范恶意袭击。）
内容-MD5="内容-MD5""：" MD5-摘要
MD5-摘要=< 由RFC 1864 定义的的 基64的128比特MD5摘要>
内容-MD5报头域可由原服务器或客户机生成，用作实体正文的完整性检验。只有原服务器或客户机可生成内容-MD5报头域；不得由代理服务器和网关生成，否则会有悖于其作为端到端完整性检验的价值。任何实体正文的接收者，包括代理服务器和网关，都可检查此域中摘要值与实体正文是否相符。
MD5摘要的计算基于实体正文的内容，包括任何所用的内容译码，但不包括任何对报文正文进行的传输编码。若接到的报文有传输编码，则必须在核对内容-MD5与所收正文之前解除编码。
这样造成的后果是：摘要完全按照它们若未经传输编码而被发出的顺序进行逐字节计算。
HTTP 将RFC 1864拓宽到允许对MIME组成的媒体类型（如multipart/*,message/rfc822）计算摘要，但这并不改变如前所述的摘要计算方法。
由此产生了一系列影响。组件类型的实体正文可能会包括多个正文部分，每一部分都有自己的MIME和HTTP报头（包括内容-MD5,内容-传输-编码，和内容编码报头）。如果正文部分有内容-传输-编码或内容编码报头，则被假定为正文部分的内容已经过编码处理，且正文部分依样包括在内容-MD5摘要中。 正文部分不得含有传输编码报头域。
不可在摘要计算或核对之前就将任何断线转换为CRLF：实际传输的文本中使用的断线转换协定必须原封不动的参与摘要计算。
注：虽然HTTP的内容-MD5定义和RFC 1864中关于MIME实体正文的完全一样， 但HTTP 实体正文在对内容-MD5的应用上仍然有几处与MIME实体正文有所区别。首先，HTTP不象MIME会用内容-传输编码，而是使用传输编码与内容编码。 其次，HTTP比MIME更多地使用二进制内容类型，故值得提出的是： 在此种情况下，用于计算摘要的字节序也即由类型定义的传输字节顺序。最后，HTTP允许文本类传输时采用数种断线协定，而不只是规范的使用CRLF的形式。
14．16 内容-范围
内容-范围实体报头与部分实体正文一起发送，用于指明在全部实体正文中，那一部分正文应该应用于何处。 范围的单位在3。12节中有定义。
内容-范围 = "内容-范围""："内容-范围-说明
内容-范围-说明 = 字节-内容-范围-说明
字节-内容-范围-说明 =字节-单位 SP
字节-范围-方面-说明 "/"
（实例-长度|"*"）
字节-范围-方面-说明 =（首字节位置 "-" 末字节位置） |"*"
实例-长度 =1*DIGIT
除非无法或很难测定，报头应指明全部实体正文的总长度。星号"*"表示生成应答信息时实例长度未知。
与字节-范围-指定符的值（参见14。35。1节）不同的是，字节-范围-方面-说明仅可指明一个范围，且必须包含首末字节的绝对位置。
其字节-范围-方面-说明的末字节值小于首字节值或实例-长度值小于等于末字节值的字节-内容-范围-说明是无效的。收到无效的字节-内容-范围-说明值时接收者必须忽略此值与随其传输的任何内容。
应答时发送状态码416（请求的范围无法满足）的服务器应在内容-范围域中填上字节-范围-方面-说明为"*"。实例-长度项指明被选资源的现有长度。状态码为206（部分内容）的应答不应将内容-范围域的字节-范围-方面-说明填为"*"。
假定实体共含1234字节，字节-范围-方面-说明项的示范值为：
头500字节： 字节0-499/1234
次500字节： 字节500-999/1234
除头500 字节外的所有： 字节500-1233/1234
末500字节： 字节734-1233/1234
当HTTP报文包含单一范围的内容时，（比如，对单一范围请求，或对一组互有覆盖但无遗漏的请求的应答）此内容在传输时内容-范围报头与内容-长度报头会显示实际传输的字节数。例如：
HTTP/1。1 206 部分内容
日期： 星期三， 1995年11月15日 06：25：24 （格林威治时间）
上次修改时间：星期三， 1995年11月15日 04：58：08 （格林威治时间）
内容-范围：字节21010-47021/47022
内容-长度： 26012
内容-类型：image/gif
当HTTP报文包含多个范围时（比如，对多个未重叠范围请求的应答），它们会被当作多部分报文来传送。
用于此目的的多部分媒体类型如附录19。2节中所述定义为"multipart/byteranges"。 其兼容性问题述于附录19。6。3中。
对单一范围请求的应答不得使用multipart/byteranges媒体类型。若对多范围请求的应答结果为单一范围，可以采用只有一个部分的multipart/byteranges媒体类型发送。无法对multipart/byteranges报文解码的客户机不得在单一请求中申请多个字节范围。
当客户机在单一请求中申请多个字节范围时，服务器应按请求中出现的顺序发回信息。
若服务器出于句法无效的原因忽略了字节-范围-说明，它应视无效的范围报头域不存在来处理请求。（正常情况下，这意味着发回含有全部实体的200应答。）
如果服务器接到请求报头域中含无法满足的范围（也即，所有字节-范围-说明值的首字节值大于所选资源现有长度）的请求（含条件-范围请求报头域的除外），则它应应答以代码416（请求的范围无法满足）（参见10。4。17节）。
注： 客户机对无法满足范围的请求报头不能指望服务器一定发回416（请求的范围无法满足）而非200（OK）的应答，因为不是所有服务器都处理这一请求报头。
14．17 内容-类型
内容-类型实体报头域指明发给接收者的实体正文的媒体类型，或在HEAD方法中指明若请求为GET时将发送的媒体类型。
内容-类型="内容-类型""："媒体类型
媒体类型有3。7节定义。 此域的示例如下：
内容-类型：text/html; charset（字符集）=ISO-8859-4
7．2．1节提供了关于确定实体媒体类型方法的进一步论述。
14．18 日期
日期头域描述消息产生的日期和时间，它和RFC822中的ORIG-DATE语义一样。域值是一个在3。3。1描述的HTTP日期；它必须用RFC1123[8]数据格式发送。
Date="Date""："HTTP-date
举个例子
Date:Tue,15 Nov 1994 08:12:31GMT
原服务器在所有的应答中必须包括一个日期头域，除了这些特例：
１ 如果应答的状态代码时１００（继续）获１０１（选者协议），相应可以在服务的选项中包括日期头域。
2 如果应答状态代码传送服务器错误，如５００（ｉｎｔｅｒｎｅｔ服务器错误）获５０３（服务器不可达），它没有困难或不可能产生有效的日期。
3 如果服务器没有时钟，不能提供合理的当前时间的近似值，这个应答没必要包括日期头域，但在这种情况下必须遵照
14．18．1节中的规则。
一个收到的消息没有日期头域的话会被接收者加上一个，如果这条消息将被那个接收者或网关储存并进由一个需要日期的协议。一个没有时钟的http执行不能缓存没有重新使之关于每一个使用有效的应答。一个http缓存，特别是一个共享的缓存，必须使用一种机制使它与外界可靠的时钟保持同步。
客户端秩序在包括实体的消息中发送日期头域，正如在PUT和POST请求的过程，甚至它是随意的。一个没有时钟的客户端不能在请求中发送日期头域。
一个日期头中的http-date没必要描述一个后续消息的产生的日期和时间。它必须描述消息产生的最有用的日期和实践的近似值。除非执行没有方法产生一个恰当的相当精确的日期和时间。理论上说，日期必须是实体产生之前的那一刻，实际上，日期能是消息产生的任何时候的时间而不会影响其语义。
14．18．1 没有时钟的原服务器的运作
一些原服务器的执行可能没有可用的时钟。一个没有时钟的原服务器不能指定一个应答断开或维持修改的值除非这些值是和系统或用户可靠的时钟资源相关联的。它可以指定一个知道的终止值，在服务配置的时间或以前，这是过去的（这允许应答的预终止而不保存每个资源分离的分割值）。
14．19 ETag
Etag应答报头域提供了请求变量的当前实体标签。与实体标签一起使用的报头由14。14，14。26，14。44节描述。
实体标签可用于比较来自同一资源的不同实体。（参见13。3。3节）
Etag="ETag" "Etag"":" 实体-标签
例：
ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""
14．20 期望
期望请求报头域用于指明客户机需要特定的服务器行为。
期望="期望""："1#期望值
期望值="100-继续"|期望值-扩展
期望值-扩展=标号["="（标号|引用-字符串） *期望-参数]
期望-参数="；"标号["="（标号|引用-字符串）]
对请求的期望域中期望值不理解或与其不相容的服务器必须应答以相应的出错状态。 如果所有期望都无法满足，服务器必须应答以417（期望失败）状态。 若请求有其他问题，则应应答以其他4xx状态。
本报头域依照可扩展语法定义，以满足将来扩展需要。若服务器接到的请求含有它不支持的期望-扩展，则它必须应答以417（期望失败）状态。
期望值的比较对于未经引用的标号（包括"100-继续"标号）是而言对个例敏感的，对引用字符串的期望-扩展而言是对个例不敏感的。
期望机制是逐站进行的：即HTTP/1。1代理服务器在无法满足请求期望时必须.回送417（期望失败）状态。 然而，期望请求报头本身却是端到端的；它必须随请求一起转发。
许多旧版的HTTP/1。0和HTTP/1。1应用程序不理解期望报头。
参见8。2。3节中100（继续）状态的使用。
14．21 过期（Expire）
"过期"实体报头域给出了在何日何时之后应答即被视为陈旧。除非首先经原服务器（或含有此实体较新拷贝的中介代理服务器缓存）确认为有效，缓存一般不会返回陈旧的缓存目录值。 请参见13。2节中对过期模型的深入论述。
其格式为由3。3。1节中HTTP-日期定义的绝对日期与时间； 它必须遵照RFC 1123的日期格式：
过期="过期""：" HTTP-日期
使用示例为：
过期： 星期四，1994年12月1日， 16：00：00 格林威治时间
注：若应答包含填有最大时限谓词（参见14。9。3节）的缓存-控制域，则谓词作用覆盖过期域。
HTTP/1。1客户机和缓存必须把其它无效的，尤其是含有"0"值的日期格式按过去值（即"已经过期"）处理。
要将应答标为"已经过期"，原服务器须发送和日期报头值相等的过期日期值。（参见13。2。4节的过期计算规则）
为标记应答为"永不过期"，原服务器须发送过期日期晚于发送应答的时间一年左右的过期日期。HTTP/1。1服务器不应发送超过将来一年的过期日期。
对于原本不可被缓存的应答而言，除非缓存控制域中另有指定，否则
过期报头域中填有将来的某一日期和时间值即是表明该应答允许缓存，