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）。例如，源服务器上对<http://www.w3.org/pub/WWW/>的请求将完全包括：
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
在所有的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://www.w3.org/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 www.cnpaf.net (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://www.w3.org/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的原服务器。这个请求被www.ics.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.