HTTP超文本传输协议-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 (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 (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 (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 (2007). All Rights Reserved.
缓存机与原服务器之间重新确认缓存条目的有效性（而不只是通向原服务器的传输路径中的下一高速缓存机），或是从原服务器处重载缓存条目。端到端的重新确认有效手续在缓存机或原服务器高估了缓存应答的过期时间时可能需要。端到端重载在缓存条目由于某些原因被侵蚀时可能需要。
如果客户机没有自己的本地缓存拷贝，即所谓"未指明的端到端重新确认有效"，或客户机没有本地的缓存拷贝，即所谓"经指明的端到端重新确认有效"， 都有可能要求端到端的重新确认有效。
客户机可用缓存-控制请求指令来指明三种行动中的一种：
端到端重载
请求包括"不缓存"缓存-控制指令，或是与HTTP/1。0客户机兼容的"Pragma:不缓存"。
请求的"不缓存"指令中不得含有域名。服务器应答这种请求时不得使用缓存的拷贝。
经指明的端到端重新确认有效
请求包括"最大-年龄=0"缓存-控制指令，从而迫使通向原服务器路径上的每一高速缓存机都与下一缓存机或服务器之间重新确认自身条目的有效性。初始请求包括由客户机现有的确认模块决定的缓存有效性确认过程。
未指明的端到端重新确认有效
请求包括"最大-年龄=0"缓存-控制指令，从而迫使通向原服务器路径上的每一高速缓存机都与下一缓存机或服务器之间重新确认自身条目的有效性。初始请求中不包括缓存条件有效性确认过程。沿途第一个含有此资源缓存条目缓存机（如果存在的话）包括决定于现有的有效性确认模块的缓存-有效性确认。
最大-年龄
当中转缓存机被"最大-年龄=0"的指令迫使重新确认其缓存条目有效性，且客户机在请求中提供了自己的有效性确认器时，所供的有效性确认器可能不同于缓存条目中现存的有效性确认模块。在这一情况下，缓存机可以在不影响句法透明性的前提下将其中的任一有效性确认模块用于自己的请求。
然而，对有效性确认器的选择可能影响性能。 最好的方法是让中转缓存机采用自己的有效性确认模块来构造请求。若服务器应答以304（未经修改），则缓存机可以将自己的确认后拷 Copyright (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服务器不应发送超过将来一年的过期日期。
对于原本不可被缓存的应答而言，除非缓存控制域中另有指定，否则
过期报头域中填有将来的某一日期和时间值即是表明该应答允许缓存，
14．22 From
From请求报头域，如果给定的话，应该（SHOULD）包括控制请求用户代理的人的互联网E-MAIL地址。这个地址应该（SHOULD）是适用于机器的，就像在RFC 822 [9]里定义的“mailbox"以及在RFC 1123 [8]修订的：
From = "From" ":" mailbox
例如：
From: webmaster@w3.org
报头域可以（MAY）用作记录日志的目的和作为认证无效或者多余请求源的方法。他不应该（SHOULD NOT）用作不安全形式的访问保护。这个域的解释是请求正在为某个给定的人执行，它承担这个方法执行的责任。特别的，自动控制代理应该（SHOULD）包括这个域这样一来如果接收端出现问题的话，对运行这个自动控制程序有责任的人能够得到联系。
这个域的互联网E-MAIL地址可以（MAY）从发出请求的互联网主机中分离出来。例如，当一个请求通过一个代理服务器是应该（SHOULD）使用原发出者的地址。
客户机不应该（SHOULD）发出没有得到用户批准的From域，因为它可能和用户的个人利益或者他们站点的安全政策冲突。强烈建议用户在任何一次请求之前能够取消，授权，和修改这个域的值。
14．23 主机（Host）
主机（Host）请求报头域说明了正在请求的资源的互联网主机和端口号，就包括在用户或者提交的资源指定的源URI中（一般是一个HTTP URL,就像在3.2.2部分描述的）。Host域的值必须（MUST）代表源URL给定的源网关或者服务器的授权命名。这允许源服务器或网关区分内部不明确的URL，例如单个IP地址上有多个主机域名的服务器的根“/”URL.
Host = "Host" ":" host [ ":" port ] ; 3.2.2节
一个没有任何追踪端口信息的“主机”暗示使用请求服务的缺省端口（例如，“80”对应HTTP URL）。例如，源服务器上对<的请求将完全包括：
GET /pub/WWW/ HTTP/1.1
Host:
在所有的HTTP/1.1请求信息中客户机必须（MUST）包括Host报头域。如果被请求的URI不包括被请求服务的互联网主机域名，那么Host报头域必须（MUST）是空值。
一个HTTP/1.1的代理服务器必须（MUST）确保它向前传递的任何报文确实包括代理服务器可识别的请求服务的适当的Host报头域。所有基于互联网的HTTP/1.1服务器必须（MUST）对任何缺少Host报头域的HTTP/1.1请求报文响应状态代码400（坏的请求）。
见5.2和19.6.1.1节和主机关联的其他请求。
14。24 If-Match
If-Match报头域是用一种方法使得它是有条件的。由以前从源获得的一个或更多实体的客户机能够校验那些实体中的一个现在包括在If-Match报头域的一系列联合的实体标签。实体标签在3.11节定义。这种特征的目的是允许用对报头进行最少量处理的方法对高速缓存信息进行有效的修正。它也用来在更新请求时防止源的错误版本无意识的修改。作为一种特殊情况，“*”匹配任何现有源的实体。
If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
如果任何一个实体标签匹配在对类似GET请求的响应中返回的实体的实体标签，或者如果给出“*”以及对那个源任何现存的实体，那么服务器可以（MAY）在执行请求的方法就好像If-Match报头域不存在一样。
服务器必须（MUST）用功能强大的比较函数来比较在If-Match中的实体标签。
如果没有一个实体标签匹配，或者给出了“*”而没有现有的实体，服务器一定不要（MUST NOT)执行请求的方法，并且返回412响应（预处理失败）。当客户机希望防止更新的方法，例如PUT，修改自从客户机上一次找到以后已经改变的源的时候，这种行为是很有用的。
如果请求将会导致除2XX或412以外的任何状态，没有If-Match报头域，那么If-Match报头必须（MUST）被忽略。
"If-Match: *" 的含义是当源服务器（或高速缓存，很可能使用Vary机制，见14.44节）选择的表示法存在时，方法就应该被执行，并且当表示法不存在时，一定不要（MUST NOT）执行。
想要更新源的请求（例如PUT）可以（MAY）包括If-Match报头域来发出信号如果相应于If-Match值的实体（单个实体标签）不再是源的表示法请求方法应订不能（MUST NOT）得到应用。这允许用户表明如果源已经改变而他们不知道的话他们不希望请求成功。
例如：
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响应（没有修改的）而没有任何报文实体。
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之外的任何情况，或者如果传递的If-Modified-Since日期是无效的，响应和对正常的GET的响应完全一样。比服务器现在的时间晚的日期是无效的。
b）如果自从If-Modified-Since日期以来变量已经修改了，响应和对正常GET的完全一样。
c）如果自从一个有效的If-Modified-Since日期以来变量没有修改过，服务器应该返回响应304（没修改）。
这种特征的目的是允许用对头部最小量的处理来有效的更新高速缓存的信息。
注释：Range请求报头域修改了If-Modified-Since的含义；完整的详细信息见 14.35。
注释：If-Modified-Since的时间是由服务器说明的，它的时钟可能和客户机的不同步。
注释：当处理一个If-Modified-Since报头域的时候，一些服务器使用精确的比较函数而不是稍差的函数，来决定是否发送响应304（没修改）。当给高速缓存确认发送If-Modified-Since报头域时为了得到最好的结果，建议客户机只要可能就采用从先前Last-Modified 报头域收到的精确日期字符串。
注释：如果客户机在If-Modified-Since报头域中用任意的日期代替从Last-Modified报头得到的对同样请求的日期，客户机应该注意到这个日期是由服务器对时间的理解来解释的事实。由于客户机和服务器之间时间编码的不同，客户机应该考虑时钟不同步和舍入的问题。这包括了如果在第一次请求的时间和后来请求的If-Modified-Since日期之间文档已经改变而出现竞争的可能性，以及如果If-Modified-Since从客户机得到的日期没有得到服务器时钟的修正而出现时钟倾斜有关问题的可能性。由于网络反应时间的原因客户机和服务器之间对不同时间基准的修正是最佳的近似。
既有If-Modified-Since报头域又有If-Match或If-Unmodified-Since报头域的请求的结果本规范没有定义。
14．26 “如果不匹配”（If-None-Match）
If-None-Match报头区伴随一种使其条件化的算法使用。一个已从源端获得
实体的客户可以校验得出：这些实体没有通过在If-None-Match报头区标明相应实体
标签而流通。此特征的目的是达到最小代价的高效缓存信息刷新。它也可以防止一
些算法无意中修改客户认为不存在而实际存在的资源。
作为特殊情况，特征值“*”匹配资源的任何当前实体。
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
如果任何实体标签与将被用来回复GET请求的实体匹配，或给出“*”且
针对该资源的实体存在，则服务器不能执行被请求的算法，除非由于资源的修改
数据不能匹配If-Modified-Since报头区提供的相应内容而被要求那样做。
与之相反，如果请求算法是GET或HEAD，服务器应回复304响应，包含有匹配实
体的缓存相关报头区。所有其它算法，服务器必须回复412状态码。
13.3节说明怎样判断两实体标签匹配.弱比较函数只能用于GET或HEAD请求。
如果没有实体标签匹配，则服务器将执行被请求的算法只当If-None-Match
报头区不存在，但必须同时也忽略请求中的If-Modified-Since报头区。即，如果没
有实体标签匹配则不能回复304响应。
如果没有If-None-Match报头区的请求最终回复非2xx及304响应，则
If-None-Match报头一定要被忽略。（见13.3.4）
"If-None-Match: *"的意思是：当源服务器选择的代表（representation）
存在时算法不可用而当七其存在时可用 此特征在防止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-None-Match报头区及If-Match或者If-Unmodified-Since（此后不可
修改）报头区的请求结果在此说明中不做定义
14．27 If-Range
如果客户机在其缓存中有实体的部分拷贝，并希望向缓存中添入整个实体的更新后拷贝，它可以在条件 GET（If-Unmodified-Since 和If-Match两者兼用或只取其一）中使用范围请求报头域。然而，若由于实体已被修改而导致条件不满足，客户机就需要再次发出获取当前整个实体正文的请求。
If-Range允许客户机“拦截”第二次请求。 简要说来，其含义为“若实体未改变，请发送我缺少的部分给我；否则，发给我整个实体”。
若客户机不具备实体的实体标签，但有上次修改日期，它可以在If-Range报头中使用此日期（服务器通过检查一两个字符即可区分合法HTTP日期与任意形式的实体标签）。If-Range报头应只和范围报头一起使用，且在请求不含范围报头或服务器不支持亚范围操作时必须被忽略。
若If-Range报头中给出的实体标签于实体当前的实体标签相吻合，则服务器应使用206（部分内容）应答来指明实体的亚范围。 若实体标签不相符，服务器应使用200（OK）应答返回整个实体。
14．28 If-Unmodified-Since
If-Unmodified-Since请求报头域用来使某方法变为条件的。若请求的资源在此域中指定的时间之后即未被修改，则服务器应按If-Unmodified-Since报头不存在的方式执行所请求的操作。
若请求的变量在给定时间之后已被修改，则服务器不得执行所请求的操作，且必须返回412（前提条件不满足）应答。
If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-日期
此域的应用实例:
If-Unmodified-Since: 星期六, 1994年10月29日 19:43:31 格林威治时间
如果正常情况下（即没有If-Unmodified-Since报头时），请求会得到除了2xx与412状态的结果，则If-Unmodified-Since报头应被忽略。
若指定的日期无效，本域亦被忽略。
本说明未定义一个既有If-Unmodified-Since报头，又有If-None-Match 或If-Modified-Since报头的请求的结果。
14．29 上次修改
上次修改实体报头域指明原服务器认为的变量上次被修改的日期和时间。
上次修改="上次修改""："HTTP-日期
应用示例如下：
上次修改： 星期二， 1994年11月15日， 12：45：26 格林威治时间
此报头域的确切含义取决于原服务器的处理和原资源的性质。 对文件而言，它可能仅仅指示文件系统上次修改时间。对动态包含各个部分的实体而言，它可能指的是其组成部分的上次修改值中最近的一个。 对数据库网关而言，它可能就是记录的上次更新时间戳。对虚拟对象而言，它可能是上次内部状态改变的时间。
原服务器不得发送迟于服务器生成此报文时间的上次修改日期。 在这种情况下资源的上次修改意味着将来的某一时刻，服务器必须以报文生成日期取代之。
原服务器应尽量在靠近其生成应答日期值的时刻获取上次修改值。 这样接收者可以更准确的估计实体的修改时间，当实体在应答生成时间的前后有所改动时尤为如此。
HTTP/1。1服务器应尽可能发送"上次修改"信息。
14．30 位置（Location）
除了应用于关于请求完成或新资源确认的请求,URI位置响应报头域还用于使收件人重发到某个地址.对 201(Created)响应,位置是请求建立的新资源.对3xx响应.Location应当指出服务器的关于资源自动重定向的首选URI.该域的值由单个绝对的URI组成.
Location = "Location" ":" absoluteURI
例如：
Location: http:///pub/WWW/People.html
注: Content-Location报头域(14.14节)不同于Location, Content-Location定义了请求附属实体的源地址.因此响应有可能既有Location报头域,也有Content-Location报头域.看13.10节一些方法的缓存需求.
14．31 最大前向(Max-Forwards)
最大前向请求头域提供一种带有TRACE(9.8节)和OPTION(9.2节)方法的机制以限制那些能够向下一个本地服务器转送请求的代理或网关.当客户尝试跟踪一个似乎失败或在中间链循环的请求链时,这一点十分有用.
Max-Forwards = "Max-Forwards" ":" 1*DIGIT
最大前向值是一个表示剩余的请求转送时间的十进制整数.
每个代理或网关接受包含最大前向头域的TRACE或OPTION请求时必须在转送请求前 Copyright (2007). All Rights Reserved.
检查和修正它的值.如果接收到的值是zero(0),接收者一定不能转送这个请求;相反,它必须像最终接收者一样响应.如果接收到的最大前向值大于0,转送的消息必须包含一个经过修正的最大前向域,其域值减一.
对本说明书定义的所有其它方法以及任何没有明确将它归作定义的一部分的扩展方法,最大前向头域可以被忽略.
14．32 实用(Pragma)
实用常规头域被用来包含特殊的执行指令，它可沿请求/接受链应用于任何接收端。从协议的观点所有的实用指示了详细的可选行为；不管怎样，一些系统可以被要求那些行为与指示的相一致。
Pragma ="pargma"":"1#pragma-directive
Pragma-directive ="no-cache"|extension-pragma
Extension-pragma =token["="(token|quoted-dtring)]
当一个非缓存的指示出现在请求的消息中，应用程序必须跟随这个原服务器的请求，甚至这是个正在被请求的缓存的复制。这个实用的指示的语义和非缓存指示（14。9节）一致，他的定义是为了和http/1.0保持一致。当一个非缓存的请求被送到一个不知道是否支持http/1.1的服务器，客户端必须包括两个头域。
使用指示必须被代理和网关应用程序过，不管对于那些应用程序有没有意义。因为这些指令可以被请求/应答链上的所有接受者应用。不可能为一个特殊的接收者定义一个实用，然而，实用指示必须被不相关的接收者忽略。
HTTP/1.1高速缓冲器必须把"Pragma：no_cache"当作客户端发送了"cache_control:no-cache".在http中不会有新的指令定义。
注意：因为Pragma: no-cache的意思并没有作为应答的头域在十几种定义，他不提供可靠的应答中Cache-Control: no-cache的替代。
14．33 代理认证(Proxy-Authenticate)
代理认证的响应头域必须是407响应的一部分.这个域的值由表示认证方案的复杂问题和应用于这个请求URI的代理的参数组成.
Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge
HTTP访问认证进程如"HTTP认证:基本和分类访问认证"[43]所描述.与www认证不同,代理认证的头域仅仅应用于当前连接,不应该转到下游客户.但是,中间代理可能需要向下游客户请求获得它自己的证书,有时候看起来这好像代理在转送代理认证头域.
14．34 代理授权
代理授权的请求头域允许客户将它自己(或的使用者)看作和需要认证的代理一样.代理授权的域值由包含用户代理对代理服务器的授权信息和正在被请求的资源界组成. [译者注]realm:数据库中的一种逻辑子域，它包含了有约定的数据的聚集的全部(具体)值.
Proxy-Authorization = "Proxy-Authorization" ":" credentials
HTTP访问认证进程如"HTTP认证:基本和分类访问认证"[43]所描述.与授权不同,代理授权的头域仅仅应用于下一个需要认证的外地代理,用的是代理认证域.当多个代理在链中使用时,代理授权的头域由第一个期待收到证书的外地代理消耗.代理可以从客户请求向下一个代理转发证书,如果那是代理协同认证给定请求的机制.
14．35 范围
14.35.1 字节范围
既然所有的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值给出了这个范围里最后一个字节的偏移量;也就是说,确定的字节位置包含在内.字节偏移量初始值为零.
如果存在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.
通过选择last-byte-pos,客户能够限制检索字节的数量而不必知道实体的大小.
suffix-byte-range-spec用来表示实体正文的后缀,其长度由后缀长度值给出.(也就是说,这种形式规定了实体正文的最后N个字节.)如果实体短于确定的后缀长度,则使用整个实体正文.
如果一个句法正确的byte-range-set至少包括一个这样的byte-range-spec:它的
first-byte-pos比实体正文的当前长度小,或至少包括一个后缀长度非零的
suffix-byte-range-spec,那么byte-range-set是可以满足的.否则是不可满足的.
如果byte-range-set是不可满足的,服务器应该返回一个带有206状态(局部内容)的响应,其中包括实体正文的可满足范围.
byte-ranges-specifier(字节-范围-说明符)值的例子(假定实体正文长度为10000):
-- 第一个500字节(字节偏移量0-499,包括0和499):
bytes=0-499
-- 第二个500字节(字节偏移量500-999,包括500和999):
bytes=500-999
-- 最后500字节(字节偏移量9500-9999,包括9500和9999):
bytes=-500 或 bytes=9500-
-- 仅仅第一个和最后一个字节(字节0和9999):
bytes=0-0,-1
-- 关于第二个500字节(字节偏移量500-999,包括500和999)的几种合法但不规范的叙述:
bytes=500-600,601-999
bytes=500-700,601-999
14.35.2 范围检索请求
HTTP检索请求使用有条件或无条件GET方法,可以利用范围请求头来请求实体的一个或更多子范围而不是整个实体,范围请求头部应用于作为请求结果返回的实体.
Range = "Range" ":" ranges-specifier
服务器可以忽落范围头.但是,HTTP/1.1源服务器和中间高速缓存应该在可能的时候支持字节范围,既然范围支持部分失败传输的有效恢复,并且支持对大实体的部分检索.
如果服务器支持范围头和确定的范围,或范围对实体是合适的:
-- 如果GET是以别的方式成功的,无条件GET里范围头的存在修改返回的东西.换句话说,响应携带的是状态代码206(部分内容)而不是200(好).
-- 如果GET以别的方式成功且条件为真,有条件GET(一种使用If-Modified-Since和If-None-Match二者之一或全部,或者 If-Unmodified-Since和If-Match二者之一或全部的请求)里范围头的存在修改返回的东西.它并不影响返回的304(未修改)响应,如果条件为假.
某些情形下,使用Range header(范围头)辅以If-Range header(假设范围头)可能更合适.
如果支持范围的代理收到范围请求,将请求转发到本地服务器,以及收到回复的整个实体,它应该只把请求的范围返回给客户.它应该将接收到的整个响应存储在高速缓存中,如果这跟它的高速缓存分配方针一致的话.
14．36 参考者（Referer）
参考者（Referer）请求头域允许客户确定获得请求URI的资源地址(URI)-为了服务器的利益.Referer请求头允许服务器生成关于到资源的反向连接(back-link)的列表,为了兴趣,记录,优化的高速缓存等等.它也允许追踪过时的或错误类型的连接(link)以便维护.如果请求URI是从一个没有自己的URI的源获得的,如从使用者键盘的输入,那么一定不要发送Referer域.
Referer = "Referer" ":" ( absoluteURI | relativeURI )
例如:
Referer: http:///hypertext/DataSources/Overview.html
如果域值是相对URI,它应该理解为与请求URI相关.URI一定不能包括片断.安全考虑请参看15.1.3节.
14．37 稍后重试
稍后重试应答报头域可以和503（服务不可达）应答一起使用，以指示服务对于发出请求的客户机而言预计有多久不可达。本域也可与任何3xx（重新定向）应答一起用于指示用户代理在重定向请求前被要求等待的最小时间。本域的值可以是应答时间只有的HTTP-日期或整值的秒数（十进制）。
稍后重试=“稍后重试”“：”（HTTP-日期|delta-秒）
应用的例子有二：
稍后重试：星期五，1999年12月31 23:59:59 格林威治时间
稍后重试：120
在后一例中，延迟时间为2分钟。
14．38 服务器
服务器应答报头域包含了原服务器用于处理请求的软件信息。 此域可包含多个产品标记（3。8节），以及鉴别服务器与其他重要亚产品的注释。产品标记按它们对于鉴别应用程序的重要性的顺序排列。
服务器=“服务器”：“1*（产品|注释）
例：
服务器：CERN/3。0 libwww/2.17
若应答是通过代理服务器转发的，则代理程序不得修改服务器应答报头域。作为替代，它应添入路由（Via）报头（如14。45节定义）。
注：揭示特定的软件版本可能会使服务器易于受到那些针对已知的软件安全漏洞的攻击。 建议服务器实现者将此域作为可设置项。
14．39 TE
TE请求报头域指明了它愿意从应答中接收哪种扩展传输编码以及是否愿接收成块传输-代码中的trailer域。其值可由关键字“trailers”，由逗号隔开的含可选接收参数的扩展传输-代码列表组成。
TE = "TE" ":" #( t-codings )
t-codings = "trailers" | (传输-扩展 [接收-参数 ] )
关键字“trailers”的存在表明客户机愿意接收如3。6。1节中定义的成块传输-代码中的trailer域。 此关键字为传输-代码值而保留，但它本身不代表一种传输-代码。
应用举例：
TE: deflate
TE:
TE: trailers, deflate;q=0.5
TE报头域仅适用于立即连接。所以无论何时HTTP/1。1消息中有TE，连接报头域（参见14。10节）中就必须提供关键字。
服务器利用下述规则，依据TE域来裁定传输-代码是否可被接受：
如果关键字“trailers”在列，则成块传输-代码总被接受。 客户机已代表它自己与下游客户机指出愿接受成块应答中的trailer域。这意味着，可能的话，客户机正申明要么所有下游客户机都愿接收转发应答中的trailer域，要么它将试图代表下游接收者暂存应答。
注：HTTP/1。1并未定义任何限制块状应答大小，以保证客户机能够暂存整个应答的方法，
若被检验的传输-代码在TE域中有列出，它就可被接受，除非伴有qvalue为0值（如3。9节定义， qvalue 的0值表示“不可接受”）。
若多个传输-代码都是可接受的，则可接受传输-代码中qvalue值最高者优先。 “成块”传输-代码的qvalue值总是1。
若TE报头域为空，或没有TE报头域，则仅有的传输-代码是“成块”。 无传输-代码的报文总是可接受的。
14．40 追踪者（Trailer）
Trailer常规域值指示在trailer消息中有给定的头域设置，此消息用成块传输编码编码的。
Trailer = "Trailer" ":" 1#field-name
一个http/1.1消息使用成块传输编码时要包括一个trailer头域，且其不能为空。这样才能让接收者知道trailer中期望得到哪个头域。
如果没有trailer头域存在，trailer不能包括任何头域。在成块传输编码中用到的trailer域的限制看3。6。1节。
Trailer头域中列出的消息头域必须不能包括下面的头域：
传输编码
内容长度
Trailer
14．41 传输-编码
传输-编码常规头域指出为了在发送者和接收者之间安全的传输而应用了什么样类型的转换。它不同于内容代码，传输代码是消息而不是实体的属性。
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
传输代码在3。6节中被定义了。一个例子是：
Transfer-Encoding: chunked
如果一个实体应用了多种编码，传输代码必须顺序列出应用的编码。关于代码参数的额外信息有其他的实体头域指定。许多旧的http/1.0应用程序不懂传输编码头。
14．42 升级(Upgrade)
升级头域允许客户端指定它支持什么样的附加传输协议并想使用如果服务器发现选择这种协议是恰当的话。服务器必须用101（选择协议）升级头域来指示要选择那个协议。
Upgrade = "Upgrade" ":" 1#product
举个例子：
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
升级头域被用来规定一种简单的机制从http/q.q过渡到其他不同性质的协议。它允许客户发出它期望使用另一个协议，比如说稍后的更高版本的http协议，甚至当前的请求已经使用了 http/1.1协议。通过允许客户端发出一个用更普通的协议的请求来指示服务器它想用更好的协议（这儿得更好的由服务器决定，可能是按照方法的自然性或被请求的资源）它减轻了两个不同性质的协议之间传输的困难。
升级头域只被用来从存在的传输层协议之上选择应用层协议。升级不能被用来强迫一个协议的改变；它的接受和使用是由服务器自由决定的。协议变换后应用层的通讯的性能和本性是由新选择的协议决定的，虽然改变协议以后的第一个动作是包含升级头域的原来http请求的应答。
升级头域只应用于直接连接，因此无论升级出现在http/1.1消息的是什么时候，升级的关键字都必须应用于连接的头域中。
升级头域不能被用来指示选择不同连接中的协议。为这个目的，使用301，302，303重定位应答更合适。
这个规范着定义了http协议的名字，它被在3。1节的http版本规则中定义的超文本传输协议家族使用。任何一个记号都可被用来做协议名字，然而，只有当客户端和服务器用同一个协议关联时才有用。
14．43 用户代理
用户代理请求头包括发出请求的用户代理的信息。这是为了统计学的目的，跟踪违反协议，为了因特定用户代理的限制制作对应响应而自动识别用户代理。用户代理必须在请求中包括这个域。这个域包括多个指明代理和构成代理的重要组件的产品标记和元素。按惯例，这些产品标记按指明应用程序的重要性的顺序排列。
User-Agent = "User-Agent" ":" 1*( product | comment )
例子:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
14．44 更正(Vary)
更正头域是在响应开始的时候变更完全接收的请求头域设置，而不管高速缓存是否允许用响应回复后续的请求。对于非高速缓存或者旧的响应，更正头域值建议用户代理用来选择请求的标准。
一个为“*”的更正域意味着高速缓存不能根据后来的请求的请求头判断而不管这个请求是否是恰当请求。高速缓存对更正头域的用法间13。6节。
Vary = "Vary" ":" ( "*" | 1#field-name )
一个HTTP/1.1的服务器的任何能缓存的响应必须包括一个更正头域，这是服务器驱动商议的科目。这样做高速缓存呢能恰当的解释下一个关于那个资源的请求同时通知用户代理需要对那个资源商议。一个服务器可以在非缓存的响应中包括更正头域，这是服务器驱动商议的科目，既然这可以提供用户代理在响应的时候响应的变化的有用信息。
一个更正头域由一张头域的表组成，响应按一个选择的法则从其中选出，这个法则在选择最恰当的响应的时候只考虑列出的请求头域。一个高速缓存会假定下一个请求的选择会和列出的头域的值一样。
此给定头域的名字不受这个说明书定义的标准请求头域的规范所限制。域名是对缓存不敏感的。
一个值为没有定义的“*”表明对请求头没有限制（例如，网络客户端的地址），作为选择响应表述的规则。“*”值一定不能由代理服务器产生；它只可以由源服务器产生。
14．45 路由（Via）
路有常规头域必须被网关和代理服务起来指示中间的协议和关于请求的使用者和服务器之间的接收者及应答的原服务器和
客户端的接收者。它类似于RFC 822[9]的接收域，被用来跟踪消息的去向，避免请求循环，及识别沿请求/应答链个发送者协议的性能。
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
接收协议指出沿请求/应答链的每一段后被服务器或客户端接收到的消息的版本。接收协议的版本被加到路由域值中，因此对于所有的接收者来说以前的所有应用程序的协议能力的信息都保留了。
协议的名字是可以选择的，只要也只有它是HTTP。接收到的域一般是通常的主机和接收服务器或客户端的可选择的端口，然而，如果真实的主机考虑信息的敏感性，它可能会用假名代替，如果没有指明端口，它被假设成接收协议的默认端口。
多重路由域值应答传递消息中的每一个代理或网关。每一个接收者必须添加上自己的信息，这样结果依照传递的应用程序的顺序范围。
路由头域可能会使用注释来识别接收的代理或网关的软件，用户代理和服务器头域也是如此。然而，所有的路由头域中的注释是可选的，它可以被任何接收的代理服务器删掉。
举个例子，一个http/1.0的用户代理发送一个叫fred的请求消息给国内的代理，它使用http/1.1来传递请求给在nowhere.com的公共代理，它把这个请求传递给在wwwlics.uci.edu的原服务器。这个请求被收到的时候应该有以下的路由头域：
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
代理和网关被作为一个通过防火墙的入口，在默认情况下，它不能传递防火墙内的主机的名字和端口。这个信息只有在明确允许下才能传播。如果不允许的话，任何在防火墙后面的主机将被用假名代替。
对于那些要求很强的隐藏内部结构的需求的机构，一个代理可以把有顺序的路由头域和同样的接收协议值组合在单个的条目中。举个例子：
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" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
[SP warn-date]
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
warn-date = <"> HTTP-date <">
警告文本必须使用自然语言，对于接收应答的使用人来说它基本上时可理解的。这个决定可以基于任何可利用的知识，比如说缓存或使用者的位置，请求中的接收语言域，应答中的内容语言域，等等。默认的语言是英语，默认的属性设置是ISO-8859-1。
如果属性设置不是使用ISO-8859-1，它必须按RFC 2047[14]中描述的在警告文本中指明。
警告头一般能被应用于任何的消息，然而一些特殊的警告代码对于高速缓存是特殊的，只能应用于应答消息。新的警告头必须加到任何存在的警告头的后面。一个高速缓存一定不能删掉它接收到的消息的警告头域。然而，如果高速缓存成功的使高速缓存条目有效，它能把符合条目的警告头都删掉除了那些特殊的警告代码。它必须马上把它接收到的警告头域加到确认应答中。用其他华说，警告头实那些能附加于最近大多数应答的应答。
当多个警告头附加于一个应答，用户代理必须按应答中显示的顺序尽可能多的通知使用者。如果不能通知所有警告的拥护，用户代理必须按这些HEURISTICS运作：
-出现在应答中前面的警告从那些出现在后面手中接过优先权
-符合用户首选性质设置的警告从其它使用相同的警告代码和警告代理但在其他性质设置的警告手中接过优先权。
产生多个警告头的系统必须按用户代理的行为排列它们。
对于注意警告的高速缓存的行为的要求在13。1。2节中规定。
这是通常定义的警告代码的列表，每一个有推荐的英语的警告文本和它意思的描述。
110 应答迟缓
当回复应答迟缓的时候应用
111 重新连接失败
当试图重新连接失败高速缓存返回一个迟缓应答，原因是服务器不可达。
112 分离操作
当高速缓存要有意从其它的网络中分离一段时间。
113 探索终止
高速缓存要选择保鲜的。生存期大于24小时，应答年龄大于24小时。
199 混合警告
警告文本可以包括只能给使用人看的信息。一个系统收到这样的警告必须给使用者看而不能自动处理。
214 转变被应用了
如果中间高速缓存或代理的任何应答的内容编码（如在内容编码头中指定的）或媒体类型（如在内容类型头指定的）或实体正文被改变了则这个警告必须被添加上去，除非这个警告代码已经出现在应答中。
299 持久混合警告
警告文本可以包括只能给使用人看的信息。一个系统收到这样的警告一定不能自动处理。
如果一个实现用http/1.0或更低的版本发送了一个又一个或多个警告头的消息，发送者必须包括和应答中匹配的每一个警告值和警告数据。
如果一个实现收到一条报文，在这条报文中警告值包括一个警告数据，这个警告数据和行营中的数据值不同，那么这个警告值必须在储藏，传递或使用以前从这条消息中删掉。这可防止错误储存警告头域）如果因为这个原因所有的警告制度被删掉了，则这个警告头也应该被删掉。
14．47 WWW-认证
401（未授权的）应答报文中必须含有WWW-认证应答报头域。 域值至少包括一个指明了可应用于请求-URI的认证方案与参数的挑战（challenge）.
WWW-认证=“WWW-认证”“：”1#挑战
HTTP访问认证过程在“HTTP认证：基本与摘要访问认证”[43]中有所描述。
建议用户代理尤其谨慎地解析WWW-认证域值，因为它可能含多个挑战，或在有多个WWW-认证报头域的情况下挑战内容本身即含有由逗号隔开的认证参数列表。
15．安全考虑
这一部分是用来提醒程序开发人员，信息提供者，和HTTP/1.1中的安全限制的用户这篇文档所叙述的事情。虽然这个讨论为减少安全风险确实提供了一些建议，但是它并不包括所透露问题的最终解决方案。
15．1 个人信息
HTTP的客户机经常对大量的个人信息是敏感的（例如用户的名字，域，邮件地址，口令，密匙等。），并且应当（SHOULD）非常小心地防止这些信息无意识地通过HTTP泄露到其他的主机。我们非常强烈地建议应该提供给用户一个方便的界面来控制这种信息的分发，并且设计者和使用者在这方面应该特别注意。历史告诉我们在这方面的错误经常引起严重的安全和/或者机要问题并导致出现对使用者的公司非常不利的公开的情况。
15.1.1服务器日志信息的滥用
服务器是处在存储个人数据的位置上，这些数据是关于用户的请求的,这些请求可以识别他们的阅读习惯或者感兴趣的主题。自然这种信息明显是机要的并且在某些国家对它的处理是受限制的。使用HTTP协议提供数据的人们有责任确保这样的材料不会在没有得到任何公开结果确认的人允许的情况下被散布出去。
15.1.2敏感信息的传输
就像任何种类的数据传输协议一样，HTTP不能控制被传输数据的内容，也没有任何一种区分的方法来决定在任何给定请求的上下文中某个特别的信息片段的敏感性。因此，应用程序应该（SHOULD）提供给发布信息的人尽可能多的对这个信息的控制能力。四个报头域是值得在这段文字中特别提到的：Server，Via，Referer和From。
暴露服务器详细的软件版本信息可能会导致服务器因为已知有安全漏洞的软件而变得更易受到攻击。开发人员应该（SHOULD）使Server报头域是一个可配置的选项。
作为通过一个网络防火墙的入口的代理服务器应该（SHOULD）对关于确认防火墙后面的主机的报头信息的传输采取特别的防范。特别的，它们应当移走或者用清洁的版本代替，Via域在放火墙后面产生。
Referer报头允许学习的阅读模式并且可以进行反向连接。虽然它非常有用，但是如果用户的资料没有从Referer包括的信息中分离出来的话它的能力就可能会被滥用。甚至当信息已经被移开，Referer报头还是可能指示出一个不适于公开的私人文档的URI。
在From域发送的信息可能和用户的个人利益或者他们站点的安全政策相抵触，因此用户如果不能使之失效，对其授权，和修改域的内容的话，它就不应该（SHOULD NOT）被传输。用户必须（MUST）能够按用户的选择或者应用程序的缺省配置设置这个域的内容。
虽然并不是必须的，我们建议向用户提供一个可以选择允许或者禁止From和Referer信息的发送的方便捆绑界面。
用户代理（14.43节）或者服务器（14.38节）的报头域有时候会被用来判断某个特定的客户机或者服务器有一个可以被利用的特别的安全漏洞。不幸的是同样的信息经常被用作其它有价值的目的因为HTTP现在没有更好的机制。
15.1.3 URI中敏感信息的编码
因为一个连接的源地址可能是机要的信息或者可能会暴露另外一个机要的信息源，所以强烈推荐用户能够选择是否发送Referer域。例如，一个浏览器的用户能够有一个捆绑的选择是公开/匿名浏览，这将会分别允许/禁止Referer和From信息的发送。
如果目标页使用安全的协议传输的话，在一个（不安全）HTTP请求中客户机不应该（SHOULD NOT）包括一个Referer报头域。
使用HTTP协议的服务提供者不应该（SHOULD NOT）使用基于使敏感数据屈服的形式的GET命令，因为这将导致在Request-URI中编码这个数据。许多现有的服务器，代理服务器，和用户代理将把请求URI日志记录在某个第三方可以看见的地方。服务器可以用基于屈服形式的POST代替。
15.1.4连接到Accept报头的机要问题
接受request-header可能暴露关于用户可以进入的所有服务器的信息。特别的Accept-language报头可能暴露用户个人的民族，因为对特殊语言的理解对特殊的同文化的民族的成员经常有很强的相关性。提供在每个请求中配置发送的Accept-language报头的选项的用户代理被坚定的鼓励让配置过程包括让用户明白有关机要泄露的信息。
对于用户代理来说一种限制机要泄露的方法是在缺省的情况下忽略发送Accept-language包头，并且如果通过寻找任何由服务器发出的变化的 response-header域，发现这样的发送能够提高服务的质量，就询问用户是否向服务器发送Accept-language报头。
在每个request中发送的为用户精心制作的accept报头域，特别如果这些包括质量价值，能够被服务器用作相关地可信赖的和长久的用户标识符。这样的用户标识符将会允许内容提供者进行单击轨迹跟踪以及允许合作的内容提供者匹配交叉服务器单击轨迹或者形成单个用户的屈从。注意对于许多并不在代理服务器后面的用户，运行用户代理的主机的网络地址也将作为长久用户的标识符。在代理服务器被用作增强保密的环境里，用户代理在提供给终端用户accept报头配置选项上应该是保守的。作为一个保密的极端措施，代理服务器应该在转发请求信息的时候过滤accept报头。提供高度报头配置能力的一般用途的用户代理应该（SHOULD）警告用户可能涉及的机要泄漏。
15．2 基于文件和路径名称的攻击
实现HTTP的原服务器应该（SHOULD）小心地限制由HTTP请求返回的文档仅仅是那些服务器管理员授权设置的。如果HTTP服务器直接把HTTP URIs翻译成文件的系统名称，服务器必须（MUST）特别注意不要提供没有授权发布给HTTP客户的文件。例如UNIX，微软Windows，和其它操作系统使用".."作为指示当前目录的上一层的路径的一部分。在这样一个系统中，如果不允许通过HTTP服务器访问那些除授权允许访问以外的资源的话，HTTP服务器就必须（MUST）禁止在Request-URI中任何这样的结构。同样的，必须（MUST）保护认为仅仅涉及服务器内部的文件（例如访问控制文件，配置文件，和剧本代码）不要被不适当的获取，因为它们可能包含敏感信息。经验表明在HTTP服务器这样的使用中次要的bug已经转变为威胁安全的风险。
15．3 DNS欺骗
客户使用HTTP严重依赖于域名服务，因此一般倾向基于故意不相关的IP地址和DNS名称的安全攻击。客户需要在假定一个IP号/DNS名称关联继续合法时谨慎。
特别的，HTTP客户对于一个IP号/DNS名称关联的确认应该（SHOULD）依靠对它们名字的解析，而不是存在高速缓存中以前主机名解析查找的结果。在适当的时候并且他们应该（SHOULD）被设置成这样做的时候，许多论坛已经能够在本地用高速缓存存储主机名。只有当域名服务器报告的TTL（现在时刻）信息使高速缓存里的信息很可能仍然是有用的时候，对这些高速缓存的查询才是适当的。
如果HTTP客户为了达到提高性能的目的把查询到的主机名结果存在高速缓存中，他们必须（MUST）遵守域名服务器报告的TTL信息。
如果HTTP客户不遵守这个规则，在一个以前访问过的服务器的IP地址改变的时候他们就会被欺骗。在网络重新编号被认为变得日益普遍的时候，这种形式的攻击的可能性将会增大。遵守这个必要条件将会因此减少这种潜在的安全隐患。
这个必要条件也改进了客户机对使用同样域名的镜像服务器的平衡加载行为并且减少了用户访问使用这种策略的站点经历失败的可能性。
15．4 Location（位置）报头和欺骗
如果单个的服务器支持互不信任的多个组织，那么它必须（MUST）检查在自称的某个组织控制下产生的应答信息中Location和Content-Location报头的值以确认他们没有企图使他们没有权限的资源无效。
15．5 内容倾向问题（Content-Disposition Issues）
RFC 1806 [35]，在HTTP中经常使用的Content-Disposition（见19.5.1节)报头就源于此，有许多非常认真的安全考虑。 Content-Disposition并不是HTTP标准版本中的一部分，但自从它被广泛应用以来，我们正在证明它对使用者的价值和风险。详细资料见 RFC 2183 [49]（对RFC 1806的升级）。
15．6 鉴定证书和空闲的客户机
现有的HTTP客户机和用户代理有代表性地不确定地保留鉴定信息。HTTP/1.1没有提供一个从服务器到直接的客户机的方法来丢弃这些保存在高速缓存里的证书。这是一个重大的需要对HTTP做进一步扩展的的缺点。在高速缓存里的证书可能干扰应用程序的安全模式的情况包括但不只限于：
--客户机已经空闲了很长时间，然后服务器可能希望引起客户机再一次出示用户的证书。
--应用程序包括了一个进程中断的指令（例如在一页上有"logout"或者"commit"的按钮），在此之后应用程序的服务器方面"知道"客户机没有进一步的理由保留证书。
这是当前分散考虑的情况下。这个问题的各部分有许多的工作区，我们鼓励在屏保程序中使用密码保护，空闲暂停，以及其它在这个问题中减轻固有安全问题的方法。特别的，在高速缓存中保存证书的用户代理被鼓励提供一个在用户控制下丢弃保存在高速缓存中的证书的可以容易访问的机制。
15．7 代理服务器和高速缓存
HTTP代理是中间人，并且扮演一个"中间者"攻击的目标。代理运行系统的妥协可能导致严重的安全和保密问题。代理有权访问与安全相关的信息，关于个人用户和组织的私人信息，属于用户和内容提供者的所有权信息。一个不安全的代理，或者一个使用或配置没有注意安全和保密考虑的代理，可能被用作广泛的潜在攻击的代理。
代理服务器的管理员应当保护代理服务器上运行的系统就像他们保护包括或者传递敏感信息的任何系统一样。特别的，在代理上聚集的日志信息经常包括高度敏感的个人信息，和/或者关于组织的信息。日志信息应该被小心地保护，并且对发展的和接下来的使用持适当的指导方针。(15.1.1节)
高速缓存代理给其它潜在的攻击提供了机会，因为高速缓存的内容对于恶意利用是一个有吸引力的目标。因为当一个HTTP请求完成以后高速缓存的内容仍然存在，对高速缓存的攻击能揭示很早以前用户就认为已经从网络上移走的信息。因此，高速缓存的内容应该当作敏感信息保护。
代理服务器的设计者应当考虑他们的设计和编码的制定，以及他们提供给代理服务器操作人员的配置选项（尤其是缺省配置）所牵涉到的保密和安全问题。
代理服务器的用户必须明白他们并不比管理代理服务器的人更值得信任；HTTP自己不能解决这个问题。
在适当的时候明智的使用密码系统可以提供足够的保护免遭广泛的针对安全和保密的攻击。这种密码系统超出了HTTP/1.1规范的范围。
15.7.1 对代理服务器的拒绝服务攻击
它们是存在的。它们很难防御。研究在继续。当心。
16 感谢（Acknowledgment)
这份规范大量使用了扩展BNF和David为RFC 822 [9]定义的类的结构。同样的，它继续使用了很多Nathaniel Borenestein和Ned Freed为MIME [7]提供的定义。我们希望在这份规范里它们包含的内容有助于减少过去在HTTP和互联网邮件消息格式关系上的混乱。
HTTP协议在这几年已经有了相当的发展。它受益域大量积极的开发人员的团体--许多人已经通过利用邮件列表的万维网交谈来分担工作--并且通常就是团体对HTTP和万维网的成功负担了其中大多数的责任。 Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois Groff , Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders, 和 Marc VanHeyningen因为他们在定义协议早期方面的贡献应该得到特别的赞誉。
这篇文档从所有那些分担HTTP-WG的人员的注释中获得了很大的益处。除了已经提到的那些人以外，下列人士对这个规范做出了贡献：
Gary Adams Ross Patterson
Harald Tveit Alvestrand Albert Lunde
Keith Ball John C. Mallery
Brian Behlendorf Jean-Philippe Martin-Flatin
Paul Burchard Mitra
Maurizio Codogno David Morris
Mike Cowlishaw Gavin Nicol
Roman Czyborra Bill Perry
Michael A. Dolan Jeffrey Perry
David J. Fiander Scott Powers
Alan Freier Owen Rees
Marc Hedlund Luigi Rizzo
Greg Herlihy David Robinson
Koen Holtman Marc Salomon
Alex Hopmann Rich Salz
Bob Jernigan Allan M. Schiffman
Shel Kaphan Jim Seidman
Rohit Khare Chuck Shotton
John Klensin Eric W. Sink
Martijn Koster Simon E. Spero
Alexei Kosut Richard N. Taylor
David M. Kristol Robert S. Thau
Daniel LaLiberte Bill (BearHeart) Weinman
Ben Laurie Francois Yergeau
Paul J. Leach Mary Ellen Zurko
Daniel DuBois Josh Cohen
高速缓存设计的许多内容和介绍应归于一下人士的建议和注释：Shel Kaphan,
Paul Leach, Koen Holtman, David Morris, 和 Larry Masinter。
大部分规范的范围是基于Ari Luotonen和John Franks早期做的工作，以及从Steve Zilles另外加入的内容。
感谢Palo Alto的"cave men"。你们知道你们是谁。
Jim Gettys（这篇文档现在的编者）特别希望感谢Roy Fielding，这篇文档以前的编者，连同John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, 和Larry Masinter一起感谢他们的帮助。还要特别感谢Jeff Mogul和Scott Lawrence对"MUST/MAY/ SHOULD"使用的检查。
Apache组，Anselm Baird-Smith，Jigsaw的作者，和Henrik Frystyk在早期实现了RFC 2068，我们希望感谢他们发现了许多这篇文档尝试纠正的问题。
17 参考资料 (Reference)
[1] Alvestrand, H., "Tags for the Identification of Languages", RFC
1766, March 1995.
[2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
D. and B. Alberti, "The Internet Gopher Protocol (a distributed
document search and retrieval protocol)", RFC 1436, March 1993.
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC
1630, June 1994.
[4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
Locators (URL)", RFC 1738, December 1994.
[5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
2.0", RFC 1866, November 1995.
[6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer
Protocol -- HTTP/1.0", RFC 1945, May 1996.
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[8] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC 1123, October 1989.
[9] Crocker, D., "Standard for The Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
Functional Specification," (v1.5), Thinking Machines
Corporation, April 1990.
[11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
June 1995.
[12] Horton, M. and R. Adams, "Standard for Interchange of USENET
Messages", RFC 1036, December 1987.
[13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC
977, February 1986.
[14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996.
[15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC
1867, November 1995.
[16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.
[17] Postel, J., "Media Type Registration Procedure", RFC 1590,
November 1996.
[18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
959, October 1985.
[19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[20] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
[21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
[22] ISO-8859. International Standard -- Information Processing --
8-bit Single-Byte Coded Graphic Character Sets --
Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
[23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC
1864, October 1995.
[24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
1900, February 1996.
[25] Deutsch, P., "GZIP file format specification version 4.3", RFC
1952, May 1996.
[26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP
Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35,
Dec. 1995. Slightly revised version of paper in Proc. 2nd
International WWW Conference '94: Mosaic and the Web, Oct. 1994,
which is available at
ency.html.
[27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP
Performance",
ISI Research Report ISI/RR-98-463, (original report dated Aug.
1996), USC/Information Sciences Institute, August 1998.
[28] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC 1305, March 1992.
[29] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996.
[30] S. Spero, "Analysis of HTTP Performance Problems,"
[31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
Digest Access Authentication", RFC 2069, January 1997.
[33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[34] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[35] Troost, R. and Dorner, S., "Communicating Presentation
Information in Internet Messages: The Content-Disposition
Header", RFC 1806, June 1995.
[36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and
Interpretation of HTTP Version Numbers", RFC 2145, May 1997.
[jg639]
[37] Palme, J., "Common Internet Message Headers", RFC 2076, February
1997. [jg640]
[38] Yergeau, F., "UTF-8, a transformation format of Unicode and
ISO-10646", RFC 2279, January 1998. [jg641]
[39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,
Lie, H., and C. Lilley. "Network Performance Effects of
HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes
France, September 1997.[jg642]
[40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996. [jg643]
[41] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998. [jg644]
[42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax and Semantics", RFC 2396,
August 1998. [jg645]
[43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", RFC
2617, June 1999. [jg646]
[44] Luotonen, A., "Tunneling TCP based protocols through Web proxy
servers," Work in Progress. [jg647]
[45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
1997.
[46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[47] Masinter, L., "Hyper Text Coffee Pot Control Protocol
(HTCPCP/1.0)", RFC 2324, 1 April 1998.
[48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Examples",
RFC 2049, November 1996.
[49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
Information in Internet Messages: The Content-Disposition Header
Field", RFC 2183, August 1997.
Copyright (2007). All Rights Reserved.
18 作者地址
Roy T. Fielding
Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425, USA
Fax: +1 (949) 824-1715
EMail: fielding@ics.uci.edu
James Gettys
World Wide Web Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682
EMail: jg@w3.org
Jeffrey C. Mogul
Western Research Laboratory
Compaq Computer Corporation
250 University Avenue
Palo Alto, California, 94305, USA
EMail: mogul@wrl.dec.com
Henrik Frystyk Nielsen
World Wide Web Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682
EMail: frystyk@w3.org
Larry Masinter
Xerox Corporation
3333 Coyote Hill Road
Palo Alto, CA 94034, USA
EMail: masinter@parc.xerox.com
Paul J. Leach
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052, USA
EMail: paulle@microsoft.com
Tim Berners-Lee
Director, World Wide Web Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682
EMail: timbl@w3.org
19 附录
19．1 互联网媒介类型message/http和application/http
这篇文档除了定义HTTP/1.1协议外，还用作互联网媒介类型"message/http"和"application/http"的规范。倘若 message/http类型遵守MIME对所有"message"类型关于路径长度和编码的限制，它就可以用来封装单独的HTTP请求和应答信息。 application/http类型可以用来封装一个或者更多HTTP请求或应答信息（非混合的）的传输路径。下列是在IANA[17]注册的。
媒介类型名称： message
媒介次类型名称： http
必须参数： 无
可选参数： 版本，信息类型
版本：封装信息的HTTP版本号（例如，"1.1"）。如果不存在，版本可以从报文的 第一行确定。
信息类型：信息类型--"request"或者"response"。如果不存在，类型可以从报文的第一行确定。
编码考虑：只有"7bit"，"8bit"，或者"二进制"是允许的。
安全考虑：无
媒介类型名称： application
媒介次类型名称： http
必须参数： 无
可选参数： 版本，信息类型
版本：封装信息的HTTP版本号（例如，"1.1"）。如果不存在，版本可以从报文的第一行确定。
信息类型：信息类型--"request"或者"response"。如果不存在，类型可以从报文的第一行确定。
编码考虑：用这种类型封装的HTTP信息是"二进制"的格式；当通过E-mail传递的时候一种合适的内容传输编码是必须的。
安全考虑：无
19．2 互联网媒介类型multipart/byteranges
当一个HTTP206（部分内容）应答信息包括很大范围的内容（对于大范围非重叠的请求的应答），这些是作为一个multipart信息报文传的。这种用途的媒介类型被称作"multipart/byteranges"。
multipart/byteranges媒介类型包括两个或者更多的部分，每一个都有自己内容类型和内容范围的域。必需的分界参数指定了用来分开每个报文部分的分界字符串。
媒介类型名称： multipart
媒介次类型名称： byteranges
必须参数： boundary
可选参数： 无
编码考虑：只有"7bit"，"8bit"，或者"二进制"是允许的。
安全考虑：无
例如：
HTTP/1.1 206部分内容
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type:multipart/byteranges;boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 500-999/8000
...第一部分...
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 7000-7999/8000
...第二部分
--THIS_STRING_SEPARATES--
注解：
1）附加的CRLFs在报文中可以优先于第一个分界字符串。
2）虽然RFC 2046 [40]允许分界字符串被应用，但是一些现有的程序对引用的分界字符串会进行错误的处理。
3）许多浏览器和服务器是按照使用multipart/x-byteranges媒介类型的byteranges规范的早期草案编码的，这个草案总是但不完全和HTTP/1.1中描述的版本兼容。
19．3 宽容的应用程序 (Tolerent Applications)
虽然这篇文档列出了HTTP/1.1这一代消息所必须的元素，但是并不是所有的程序在实现的时候都是正确的。因此我们建议当偏差可以明确解释的时候操作程序对这种偏差应该是宽容的。
客户机在分析状态行的时候应该（SHOULD）是宽容的并且服务器在分析请求行的时候也是（应该）是宽容的。特别的，甚至在域之间只需要一个SP的时候，他们也应该（SHOULD）接收任意数量的SP或者HT字符。
消息报头域的结束行是顺序CRLF。然而我们建议在解析这样的报头的时候，程序应该接受单个的LF作为一行的结束并忽略第一位的CR。
一个实体正文的特征设置应该（SHOULD）分成基本的类并用那个报文中的特征代码来命名，除非无分类实体的优先级比用US-ASCII或ISO-8859-1分类的实体高。见3.7.1和3.4.1。
对关于时间的分析和编码以及时间编码的其它潜在问题的需要的附加规则包括：
--HTTP/1.1客户机和高速缓存应该（SHOULD）假定一个似乎是50多年以后的RFC-850日期实际上是过去的（这有助于解决"2000年"问题）。
一个HTTP/1.1的实现可以（MAY）在内部表现为分析完成时间比正确日期更早，但是一定不要（MUST NOT）在内部表现为分析完成时间比正确日期更晚。
--所有与结束时间有关的计算必须（MUST）用格林尼治时间。本地市区一定不能（MUST NOT）影响年龄或完成时间的计算和比较。
--如果一个HTTP报头不正确的携带了一个格林尼治时间以外其它市区的时间，它必须（MUST）用所有可能中最保守的方法转换成格林尼治时间。
19．4 HTTP实体和RFC 2045实体之间的区别
HTTP/1.1使用了许多为网际邮件（RFC 822 [9]）和多用途网际邮件扩充（MIME [7]）定义的允许在一个开放的表现多样的环境中用扩展的机制传输实体的结构。不论如何，RFC 2045讨论邮件，HTTP有一些功能部件和RFC 2045中描述的不同。这些不同被小心地挑选出来优化二进制连接的性能，允许使用新媒介类型有更大的灵活性，是时间比较更容易，并且承认一些早期HTTP 服务器和客户机的规则。
这个附录描述了HTTP和RFC 2045不同的特殊区域。在严格的MIME环境中的代理服务器和网关应该（SHOULD）意识到这些不同并且在必要的地方提供这种转换。从MIME环境到HTTP的代理服务器和网管也需要意识到这些不同因为一些转换可能是需要的。
19.4.1 MIME版本
HTTP不是一个遵守MIME的协议。然而HTTP/1.1消息可以（MAY）包括单个MIME版本的普通报头域来指出构造这个消息使用的MIME协议的版本。
MIME版本的报头域的使用表明这个消息是完全遵守MIME协议的（RFC 2045[7]定义的）。在输出HTTP消息到严格MIME环境的时候代理服务器/网关有责任确保（在可能的地方）完全匹配。
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
在HTTP/1.1用的缺省值是MIME1.0版本。然而，HTTP/1.1消息的分析和语义是由这篇文档而不是MIME规范定义的。
19.4.2 转换到规范形式
RFC 2045 [7]需要网际通信实体在传输以前先转换成规范形式，就像在RFC 2049 [48]第4部分中描述的那样。这篇文档的3.7.1节描述了当用HTTP传输时允许使用的"文本"媒介的次协议的形式。RFC 2046需要关于"文本"类型的内容就像CRLF一样代表行间隔符并禁止在行间隔符序列以外使用CR或者LF。HTTP允许CRLF，单独的CR，和单独的LF来指出在一个消息用HTTP传输的时候文本内容里的行间隔符。
在可能的地方，从HTTP到严格的MIME环境的代理服务器或者网关应该（SHOULD）把本文档3.7.1节描述的文本媒介类型里的所有行间隔符翻译成RFC 2049 CRLF的规范形式。然而注意当出现内容的编码以及HTTP允许使用一些不用八位组的13和10表示CR和LF的特殊设置的实际，就像一些多位组的特殊设置的情况，这可能是复杂的。
使用者应该注意转换将会破坏任何用于原内容的密码校验和，除非原内容已经是规范形式。因此，对任何在HTTP中使用这种校验和的内容建议表示为规范形式。
19.4.3 日期格式的转换
为了简化日期比较的过程HTTP/1.1使用了一种限定的日期格式设置。从其它协议过来的代理服务器河网馆应该（SHOULD）确保消息里现在的任何日期报头域符合一种HTTP/1.1的格式，如果必要的话重写日期。
19.4.4 内容编码的介绍
RFC 2045不包括任何相当于HTTP/1.1的内容编码报头域的概念。既然从HTTP到服从MIME协议的代理和网关作为媒介类型的修正者，它就必须（MUST）改变内容类型报头域的值或者在向前传送消息以前解码实体正文。（一些网际通信内容类型的试验程序已经使用了媒介类型参数";conversions="来实现等效于媒介编码的功能。不管怎样，这个参数不是RFC 2045的一部分。）
19.4.5 无内容传输编码
HTTP不使用RFC 2045的内容传输编码（CTE）。从使用MIME协议到HTTP的代理和网关必须（MUST）在把应答信息传给HTTP客户机之前删除任何非实体CTE（"quoted-printable"或"base64"）编码。
从HTTP到使用MIME协议的代理和网关有责任确保信息对那个协议来说是用正确的格式和编码在安全的传输，在那"安全传输"的定义是由使用的协议的限制给出的。如果分类将提高用目标协议安全传输的可能，代理或网关就应该（SHOULD）用合适的内容传输编码对数据进行分类。
19.4.6 传输编码的介绍
HTTP/1.1介绍了传输编码报头域（14.41节）。代理/网关必须（MUST）在（经过）使用MIME协议（的网段）向前传递消息以前删除任何传输编码。
一个解码"chunked"传输代码（3.6节）的程序可以用假代码表示如下：
length := 0
read chunk-size, chunk-extension (if any) and CRLF
while (chunk-size > 0) {
read chunk-data and CRLF
append chunk-data to entity-body
length := length + chunk-size
read chunk-size and CRLF
}
read entity-header
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
19.4.7 MHTML和行长度限制
和MHTML程序共享代码的HTTP程序需要了解MIME行长度限制。既然HTTP没有这个限制，HTTP并不压缩长的行。用HTTP传输的MHTML消息遵守所有MHTML的规定，包括行长度的限制和压缩，规范化等，既然HTTP传输所有作为有效载荷的消息实体（见3.7.2节）并且不说明内容或任何可能包括在那的MIME报头行。
19.5 其它特点
RFC 1945和RFC 2068记录了一些现有的对HTTP的实现所用到的协议原理，但是对于大多数软件既不兼容也不正确。他们中的一些描述了计划的实验的特征，一些描述了被发现缺少建立在HTTP/1.1规范基础上的地址的实验部署的特征。
许多从SMTP和MIME来的其它的报头，例如内容处理和标题，也经常实现（见RFC 2076 [37]）。
19.5.1 内容处理
内容处理应答报头已经被计划为一种如果用户请求把内容存成一个文件原服务器提供一个缺身文件名的方法。这种用法来自RFC 1806 [35]的定义。
content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm )
disposition-type = "attachment" | disp-extension-token
disposition-parm = filename-parm | disp-extension-parm
filename-parm = "filename" "=" quoted-string
disp-extension-token = token
disp-extension-parm = token "=" ( token | quoted-string )
一个例子是：
Content-Disposition: attachment; filename="fname.ext"
接收用户的代理不应该（SHOULD NOT）注意任何在文件名的参数中出现的文件路径信息，这个参数被认为仅仅是一个在这一次申请应用HTTP的参数。文件名应该（SHOULD）只被当作终端的一部分。
如果在应答中用到的报头有程序/八位字节流内容类型，这暗示用户代理不应该现实应答（信息），而直接开始应答...'dialog。
见15.5节内容处理的安全问题。
19.6 和以前版本的兼容
要求和以前的版本的兼容超出了协议规范的范围。然而HTTP/1.1有意设计成很容易支持以前的版本。在写这份规范的时候，值的记录下我们希望商业化的HTTP/1.1服务器是：
--接受HTTP/0.9,1.0和1.1请求的请求行格式；
--懂得HTTP/0.9,1.0或1.1格式中的任何有效请求；
--恰当地用客户机使用的主要版本回复信息。
并且我们希望HTTP/1.1的客户机：
--接受HTTP/1.0和1.1应答的状态行格式；
--懂得HTTP/0.9,1.0或1.1的格式中任何有效的应答。
对大多数HTTP/1.0的实现，每一个连接的建立是通过客户机先发出请求在服务器应答后关闭。一些实现了在RFC 2068 [33]的19.7.1节描述的Keep-Alive的牢固连接的版本。
19.6.1 对HTTP/1.0的改变
这一部分总结HTTP/1.0和HTTP/1.1之间主要的区别。
19.6.1.1 对简单的多主机web服务器和保留IP地址的改变
客户机和服务器支持主机请求报头,如果主机的HTTP/1.1请求的请求报头（14.23节）不存在就报告出错，并且接受绝对的URIs（5.1.2节）是本规范定义的最重要的改变。
老的HTTP/1.0客户机假定IP地址和服务器是一对一的关系。没有其它确定的机制区别有意对服务器的请求和直接对IP地址的请求。一旦老的HTTP客户疾步在普遍上文概述的改变将允许互联网支持一个IP地址多重WEB站点，极大简化了对WEB服务器的控制，对一个主机分配多个IP地址已经导致严重的问题。互联网也能从新获得已经分配给用在顶层HTTP URLs只单独为了某个特殊用途的域名的IP地址。给定WEB增加的速度，已经配置的服务器的数量，所有对HTTP的实现（包括对现有HTTP/1.0的程序的升级）正确的实现这些要求是非常重要的：
--客户机和服务器都必须（MUST）支持主机请求报头。
--发送HTTP/1.1请求的客户机必须（MUST）发送主机报头。
--如果HTTP/1.1请求不包括主机请求报头服务器就必须（MUST）报告错误400（Bad Request）。
--服务器必须（MUST）接受完全URIs。
19.6.2 和HTTP/1.0持续连接的兼容
一些客户机和服务器可能希望和一些对以前实现HTTP/1.0持续连接的客户机和服务器兼容。单个持续连接不是缺省的行为的时候，它就被明确的越过。 HTTP/1.0持续连接的实验性实现是有缺陷的，在HTTP/1.1中设计新的简单的来纠正这些问题。问题是一些现有的1.0客户机可能发送Keep- Alive给一个不明白这种连接的代理服务器，那么就错误地将它传向下一个接收服务器，它将建立一个Keep-Alive连接并导致一个挂着的 HTTP/1.0代理等待关闭的应答。结果是HTTP/1.0客户机必须禁止使用Keep-Alive和代理交谈。
然而，和代理交谈是持续连接最重要的用处，所以禁止很明显是无法接受的。因此，我们需要一些其它的机制来表明渴望持续连接，甚至当和一个忽略 Connection的老代理交谈这样使用也是安全的。对HTTP/1. 0消息持续连接是缺省的;我们引入一个新的关键字(Connection: close)来申明非持续。见14.10节。
原始的持续连接HTTP/1.0的形式（the Connection: Keep-Alive and Keep-Alive header）记录在RFC 2068 [33]。
19.6.3 对RFC 2068的改变
这篇规范已经被仔细的审查来纠正关键字的用法和消除它们的歧义；RFC 2068在遵守RFC 2119 [34] 制定的协定方面有很多问题。
澄清哪个错误代码将会使入站服务器失灵（例如DNS失灵）。（10.5.5节）
CREATE有一个特点当一份资料第一次创建的时候他必须发送一个Etag。（10.2.2节)
从规范中删除了内容基：它无法广泛的实现，并且除了精力充沛的扩展机制以外没有简单，安全的方法把它引入。此外它以类似但不一样的方式在MHTML [45] 中使用。
传输译码和消息长度以当使用chunked编码（允许传输自己不划界的编码）需要正确匹配的方式相互影响；正确的弄清如何计算消息长度是重要的。（3.6,4.4,7.2.2,13.5.2,14.13,14.16节）
引入"身份"的内容译码来解决高速缓存中发现的问题。（3.5节）
零值的性质应该表明"我什么都不想要"以允许客户机拒绝请求。（3.9节）
RFC 2145已经澄清了HTTP版本号的使用和解释。需要代理升级他们为了处理在实现HTTP/1.0中发现的问题而要求支持的最高协议版本。（3.1节）
统配符字符设置的引入是为了避免在接受报头的性质设置名称的激增。（14.2节）
HTTP/1.1的高速缓存控制模式中的一种情况被遗漏了；引入s-maxage是为了补充这种情况。（13.4，14.8，14.9，14.9.3节）
高速缓存控制：为了应答而定义的最大生存时间指标是不恰当的。（14.9.3节）
有服务器（尤其是代理）不知道应答的全部长度但仍可以应答比特流请求的情况。我们因此需要一个机制允许内容范围并不指示消息全部长度的比特流。
如果总是回复所有的meta-data范围请求应答将变得非常冗长；通过允许服务器在206应答中只发送必要的报头，这个问题能够避免。（10.2.7,13.5.3,和14.27节）
解决不能满足请求范围的问题；有两种情况：语法问题,以及范围在文档中不存在。需要状态416代码确定这种模糊，它必须指出一个超出文档实际内容的比特请求范围错误。 (10.4.17, 14.16节)
消息传输重写的需要使得明白错误的事先更加困难，因为这里错误的结果对互联网有重大的影响，要应付下列问题：
1.把"HTTP/1.1或以后的版本"变成"HTTP/1.1"，这不适当的设置了对未来HTTP/1.x版本实现行为的要求。
2.一般是用户代理而不是客户机应该重发请求这一点要清楚。
3.把对客户机忽略不希望的100（以后）应答，以及对代理转发应答100的要求变为对应答1xx的一般要求。
4.修改一些特殊TCP语言，使得HTTP可以用非TCP传输这一点更清楚。
5.要求原服务器在发送必须的应答100(扩展)之前一定不要（MUST NOT）等待请求主体。
6.如果服务器已经看见一些请求主体，允许，不是必须，它忽略100（扩展）。
7.允许服务器防范拒绝服务攻击和被控制的客户机。
这个变化增加了期待的报头和状态417代码。消息传输要求的修改在8.2，, 10.4.18，8.1.2.2, 13.11, 和14.20节。
代理应该可以在适当的时候增加内容的长度。（13.5.2节）
整理应答403和404之间的混乱。（10.4.4, 10.4.5, 和10.4.11节）
警告可能被错误的隐藏起来，或者没有得到适当的纠正。（13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, 和14.46节）警告也需要有一个普通的报头，因为PUT或其它命令可能需要它。
传输译码有重要的问题，特别是由于用chunked编码的交互作用。解决的办法是把传输译码变得和内容译码一样快速。这涉及到给传输译码增加一个IANA 注册（从内容译码中分离），一个新的报头域（TE）和未来授权跟踪报头。传输编码性能有很主要的好处，所以修改它是值得的。TE也解决其它的，不太明显的，因为跟踪认证，chunked编码和HTTP/1.0客户机之间相互作用而出现的向下兼容的问题。（3.6, 3.6.1, 和14.39节）
补丁，连接，解除连接的方法在这份规范以前的版本中定义过但不能一般的实现。见RFC 2068 [33]。
变化，内容版本，源，连接，URI，公开和内容基报头域在这份规范以前的版本中定义过，但不能一般地实现。见RFC 2068 [33]。
20 索引 (Index)
参见这份RFC对索引的后记部分。
21 全部版权声明
版权所有（C）INTERNET SOCIETY（1999）。保留所有权利（All rights reserved)。
如果所有的复制和派生工作包括上面的版权声明和这一段，那么这篇文档和它的翻译就可以拷贝并提供给其他人，就可以准备，复制，出版和发行，全部或者部分，注释或其它的解释或在它的实现中的帮助等派生工作，而没有任何的限制。然而，无论如何这篇文档本身不能被修改，例如删除版权声明或INTERNET SOCIETY及其它互联网组织的参考数目，除非为了发展互联网标准的目的，在这种情况下互联网标准进程定义的版权程序必须得到遵守，或者需要把它翻译成英语之外的语言。
上面准许的有限许可是永久的并且不会被INTERNET SOCIETY或者它的后继组织或分支机构撤回。
这篇文档和里面包含的内容是在"AS IS"的基础上并且INTERNET SOCIETY和INTERNET ENGINEERING TASK FORCE放弃所有的理由，明确的或者暗指的，包括但不限于任何使用这里的信息将不会破坏任何的权利理由或任何商业或适当的特殊目的的隐含的理由。
感谢(Acknowledgment)
RFC编辑活动的资金由Internet Society提供。
Copyright (2007). All Rights Reserved.
阅读(4339) | 评论(0) | 转发(0) |
