[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
http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat
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,"
http://sunsite.unc.edu/mdma-release/http-prob.html.
[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 www.cnpaf.net (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=
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 www.cnpaf.net (2007). All Rights Reserved.