19 附录
19.1 互联网媒体类型message/http和application/http
这篇文档除了定义HTTP/1.1协议外，还用作互联网媒介类型"message/http"和"application/http"的规范。此类型用于封装一个HTTP请求消息或响应消息，这假设此类型遵循MIME对 所有“消息”类型关于行长度和编的限制。application/http类型可以用来封装一个或者更多HTTP请求或响应信息（非混合的）的传输路径（pipeline）。下列是在IANA[17]注册的。
媒介类型名称： message
媒介次类型名称： http
必须参数： 无
可选参数： 版本，信息类型
版本：封装信息的HTTP版本号（例如，"1.1"）。如果不存在，版本可以从消息的第一行确定。
信息类型：信息类型–"请求"或者"响应"。如果不存在，类型可以从报文的第一行确定。
编码考虑：只有"7bit"，"8bit"，或者"二进制"是允许的。
安全考虑：无
媒介类型名称： application
媒介次类型名称： http
必须参数： 无
可选参数： 版本，信息类型
版本：封装信息的HTTP版本号（例如，"1.1"）。如果不存在，版本可以从报文的第一行确定。
信息类型：信息类型–"request"或者"response"。如果不存在，类型可以从报文的第一行确定。
编码考虑：用这种类型封装的HTTP信息是"二进制"的格式；当通过E-mail传递的时候一种合适的内容传输编码是必须的。
安全考虑：无
19.2 互联网媒体类型multipart/byteranges
当一个HTTP206（部分内容）响应信息包含多个范围的内容（请求响应的内容有多个非重叠的范围），这些是作为一个多部分消息主体来被传送的。这种用途的媒体类型被称作"multipart/byteranges"。
multipart/byteranges媒体类型包括两个或者更多的部分，每一个都有自己Content-type和Content-Range头域。必需的分界参数（boundary parameter）指定分界字符串，此分界字符串用来隔离每一部分。
媒介类型名称： multipart
媒介次类型名称： byteranges
必须参数： boundary
可选参数： 无
编码考虑：只有"7bit"，"8bit"，或者"二进制"是允许的。
安全考虑：无
例如：
HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-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–
注意：
在实体（entity）中，在第一个分界字符串之前可以有多余的CRLFs。
虽然RFC 2046 [40]允许分界字符串加引号，但是一些现有的实现会不正确的处理分界字符串
许多浏览器和服务器是按照字节范围标准的早期草案关于使用multipart/x-byteranges媒体类型来进行编码的的，这个草案不总是完全和HTTP/1.1中描述的版本兼容。
19.3 宽松的应用程序 （Tolerent Applications）
虽然这篇文档列出了HTTP/1.1消息所必须的元素，但是并不是所有的程序在实现的时候都是正确的。因此我们建议当偏差可以明确解释的时候，运算程序对这种偏差应该是宽容的。
客户端应该宽松的解析Status-Line（状态行）；服务器也应该宽松的解析Request-Line（请求行）。特别的，他们应该可以接受头域之间任何数量的SP或HT字符，即使协议规定只有一个SP。
消息头域的行终结符是CRLF。然而，当解析这样的头域时，我们建议应用程序能识别单一LF作为行终结符并能忽略CR。
实体主体（entity-body）的字符集应该被标记为应用于实体主体字符编码的最小公分母，并且期望不对实体进行标记要优于对实体标记为US-ASCII或ISO-8859-1。见3.7.1和3.4.1。
对关于日期分析和编码的要求的额外规则以及其它对日期编码的潜在问题包含：
Ø HTTP/1.1客户端和缓存应该假定一个似乎是50多年以后的RFC-850日期实际上是过去的（这有助于解决"2000年"问题）。
Ø 一个HTTP/1.1的实现可以内部地表示一个比正确日期值更早的已解析后的Expires日期，但是一定不要（MUST NOT）内部地表示一个比正确日期值更迟的已解析过的Expires日期。
Ø 所有过期日期相关的计算必须用GMT时间。本地时区一定不能（MUST NOT）影响年龄或过期时间的计算。
Ø 如果一个HTTP头域不正确的携带了一个非GMT时间区的日期值，那么必须利用最保守的可能转换把此日期值转换成GMT时间值。
19.4 HTTP实体和RFC 2045实体之间的区别
HTTP/1.1使用了许多Internet Mail（RFC 822 [9]）和Multipurpose Internet Mail Extensions（MIME [7]）里定义的结构，去允许实体以多种表现形式和扩展机制去传输。然而，RFC2045讨论邮件，并且HTTP有许多不同于RFC2045里描述的特征。这些不同被小心地挑选出来优化二进制连接的性能，为了允许使用新的媒体类型有更大的灵活性，为了使时间比较变得容易，和为了承认一些早期HTTP服务器和客户端的实效。
本附录描述了HTTP协议不同于RFC 2045的特殊区域。在严格的MIME环境中的代理和网关应该意识到这些不同并且在必要的时候要提供合适地转换。从MIME环境到HTTP的代理服务器和网关也需要意识到这些不同因为一些转换可能是需要的。
19.4.1 MIME版本（MIME-Version）
HTTP不是一个遵守MIME的协议。然而HTTP/1.1消息可以（MAY）包含一个单独的MIME-Version常用头域用来指出什么样的MIME协议版本被用于去构造消息。利用MIME-Version头域指明完全遵循MIME协议的消息（在RFC2045[7]）。代理/网关要保证完全遵守MIME协议当把HTTP消息输出到严格MIME环境的时候。
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
在HTTP/1.1用的缺省值是MIME1.0版本。然而，HTTP/1.1消息的解析和语义是由本文档而不是MIME规范定义的。
19.4.2转换到规范化形式 （Conversion to Canoical Form）
RFC 2045 [7]需要一个Internet mail实体在被传输之前要被转换成一个规范化的形式，这在RFC2049[48]里第四章里描述的。这篇文档的3.7.1节描述了当用HTTP协议传输时允许使用的”text”子媒体类型的形式。RFC2046要求以类型为“text”的内容要用CRLF表示为换行符，以及在换行符外禁止使用CR或LF。
RFC 2046需要像在"text"类型的内容里一样，用CRLF表示行间隔符并禁止在行间隔符序列以外使用CR或者LF。HTTP允许CRLF，单个CR，和单个LF来表示一个换行符在一个文本内容消息中。
在可能的地方，从HTTP到严格MIME环境的代理或网关应该（SHOULD）把RFC2049里描述的text媒体类型里所有换行符转换成RFC2049里CRLF的规范形式。然而，注意这可能在Content-Encoding出现的时候，以及HTTP允许利用一些没有利用13和10代表CR和LF的字符集时候都会变得复杂。
实现者应该注意转换将会破坏任何应用于源内容（original content）的密码校验和，除非源内容已经是规范化形式。因此，对任何在HTTP中使用校验和的内容被建议要表示为规范化形式。
19.4.3日期格式的转换 （Conversion of Date Formate）
为了简化日期比较的过程，HTTP/1.1使用了一个限制的日期格式（3.3.1节）。其它协议的代理和网关应该保证任何消息里出现的Date头域应该遵循HTTP/1.1规定的格式，如果有必要需要重写此日期。
19.4.4 Content-Encoding头域介绍 （Introduction of Content-Encoding）
RFC 2045不包含任何等价于HTTP/1.1里Content-Encoding头域的概念。因为这个头域作为媒体类型（media type）的修饰，从HTTP协议到MIME遵守的协议的代理和网关在转发消息之前必须既能改变Content-Type头域的值，也能解码实体主体（entity-body）.。（一些为Internet mail类型的Content-Type的实验性的应用已经使用了一个媒体类型参数“; conversions=<content-coding>”去执行等价于Content-Encoding的功能。然而，此参数并不是RFC2045的部分）
19.4.5没有Content-Transfer-Encoding头域
HTTP不使用RFC 2045里的Content-Transfer-Encoding（CTE）头域。从使用MIME协议到HTTP的代理和网关在把响应消息发送给HTTP客户端之前必须删除任何非等价（non-identity，译注：identity编码，表示没有进行任何编码）CTE（"quoted-printable"或"base64"）编码。
从HTTP到MIME协议遵循的代理和网关要确保消息在那个协议安全传输上是用正确的格式和正确的编码，“安全传输”是通过使用的协议的限制而被定义的。这样一个代理或网关应该用合适的Content-Transfer-Encoding头域来标记数据如果这样做将提高安全传输的可能性。
19.4.6 Transfer-Encoding头域的介绍
HTTP/1.1介绍了Transfer-Encoding头域（14.41节）。代理/网关在转发经由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应用程序既不兼容也不正确。实现者被建议去了解这些特征，但是不能依赖于它们的出现或不依赖于与其它HTTP/1.1应用程序的互操作性。这些特征中的一些特征描述了实验性的特征，以及还有一些特征描述了没有在基本HTTP/1.1规范里被描述的实验性部署特征。
一些其它头域，如Content-Dispositon和Title头域，他们来自于SMTP和MIME协议，他们同样经常被实现（见2076[37]）.
19.5.1 Content-Disposition
Content-Disposition响应头域被建议作为一个这样的用途，那就是如果用户请求要使内容被保存为一个文件，那么此头域被源服务器使用去建议的一个缺省的文件名。此用途来自于RFC1806[35]关于对Content-Disposition的定义。
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）关注任何在filename-parm参数中出现的文件路径信息，这个参数被认为在这次仅仅是应用于HTTP实现。文件名应该（SHOULD）只被当作一个终端组件。
如果此头域用于一个Content-Type为application/octet-stream响应里，那么含义就是用户代理不应该展现响应，但是它应该直接进入一个‘保存响应为…’对话框。
见15.5节关于Content-Disposition的的安全问题。
19.6 和以前版本的兼容
要求和以前的版本的兼容超出了协议规范的范围。然而HTTP/1.1有意设计成很容易支持以前的版本。必须值得注意的是，在写这份规范的时候，我们希望商业的HTTP/1.1服务器去：
–接受HTTP/0.9，1.0和1.1请求的请求行（Request-Line）格式；
–理解HTTP/0.9，1.0或1.1格式中的任何有效请求；
–恰当地用客户端使用的主要版本来响应。
并且我们希望HTTP/1.1的客户端：
–接受HTTP/1.0和1.1响应的状态行（Status-Line）格式；
–懂得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地址简化的改变
客户端和服务器必须支持Host请求头域，并且如果Host请求头域在HTTP/1.1请求里缺少，那么服务器应该报告一个错误，并且服务器能接受一个绝对URIs（5.1.2节），对于这个要求是在此规范里最重要的改变。上面的改变将允许互联网，一旦旧的客户端不再常用时，去支持一个IP地址的多个web站点，这大大简化了大型运算的web服务器，在那里分配多个IP地址给一个主机（host）会产生很严重的问题。此互联网照样能恢复这样一个IP地址，此IP地址作为特殊目的被分配给被用于根级HTTPURLs的域名。给定web的增长速度，服务器的部署数量部，那么所有HTTP实现（包括对已存HTTP/1.0应用程序）应该正确地满足下面这些需求：
–客户端和服务器都必须（MUST）支持Host请求头域。
–发送HTTP/1.1请求的客户端必须（MUST）发送Host头域。
–如果HTTP/1.1请求不包括Host请求头域，服务器就必须（MUST）报告错误400（Bad Request）。
–服务器必须（MUST）接受绝对URIs（absolute URIs）。
19.6.2和HTTP/1.0持续连接的兼容
一些客户端和服务器可能希望和一些对以前持续连接实现的HTTP/1.0客户端和服务器兼容。HTTP/1.0持久连接需要显示地协商，因为它们不是缺省的行为。持久连接的HTTP/1.0实验性的实现有错误，并且HTTP/1.1里的新的功能被设计成去矫正这些问题。此问题是一些已经存在的1.0客户端可能会发送Keep-Alive头域给不理解连接的代理服务器，然后代理服务器会把此Keep-Alive转发给下一个入流（inbound）服务器。所以HTTP/1.0客户端必须禁止利用Keep-Alive当和代理会话的时候。
然而，和代理进行会话最重要是利用持久连接，所以那个禁止很显然不能被接受。因此，我们需要一些其它的机制去指明需要一个持久连接，并且它必须能安全的使用甚至当和忽略连接的老代理。持久连接缺省是为HTTP/1.1消息的；为了声明非持久连接（见14.10节），我们介绍一个新的关键字（Connection：close）。
持久连接的源HTTP/1.0的形式（the Connection: Keep-Alive and Keep-Alive 头域）在RFC2068里说明
19.6.3对RFC 2068的改变
这篇规范已经被仔细的审查来纠正关键字的用法和消除它们的歧义；RFC 2068在遵守RFC 2119 [34] 制定的协定方面有很多问题。
澄清哪个错误代码将会使入流服务器失灵（例如DNS失灵）。（10.5.5节）
Create有一个特点当一个资源第一次被创建的时候必须需要一个Etag。（10.2.2节）
Content-Base头域从此规范里删除了：它无法广泛的实现，并且在没有健壮的扩展机制的情况下，没有简单的，安全的方式去介绍它。并且，它以一种相似的而不是相同的方式在MHTML[45]里被使用。