17. 参考文献 (References)

17 参考文献

下列参考文献中, 文献标题已译为中文, 作者姓名, RFC 编号, 出版信息与 URL 沿用英文原始写法, 以避免书目信息失真.

[1] Alvestrand, H., 《用于标识语言的标签》, RFC 1766, 1995 年 3 月.

[2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D. and B. Alberti, 《互联网 Gopher 协议（一种分布式文档搜索与检索协议）》, RFC 1436, 1993 年 3 月.

[3] Berners-Lee, T., 《万维网中的统一资源标识符》, RFC 1630, 1994 年 6 月.

[4] Berners-Lee, T., Masinter, L. and M. McCahill, 《统一资源定位符（URL）》, RFC 1738, 1994 年 12 月.

[5] Berners-Lee, T. and D. Connolly, 《超文本标记语言 2.0》, RFC 1866, 1995 年 11 月.

[6] Berners-Lee, T., Fielding, R. and H. Frystyk, 《超文本传输协议 HTTP/1.0》, RFC 1945, 1996 年 5 月.

[7] Freed, N. and N. Borenstein, 《多用途互联网邮件扩展（MIME）第一部分：互联网报文主体的格式》, RFC 2045, 1996 年 11 月.

[8] Braden, R., 《互联网主机的要求——通信层》, STD 3, RFC 1123, 1989 年 10 月.

[9] Crocker, D., 《ARPA 互联网文本报文格式标准》, STD 11, RFC 822, 1982 年 8 月.

[10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., Sui, J., and M. Grinbaum, 《WAIS 接口协议原型功能规范》（v1.5）, Thinking Machines Corporation, 1990 年 4 月.

[11] Fielding, R., 《相对统一资源定位符》, RFC 1808, 1995 年 6 月.

[12] Horton, M. and R. Adams, 《USENET 报文交换标准》, RFC 1036, 1987 年 12 月.

[13] Kantor, B. and P. Lapsley, 《网络新闻传输协议》, RFC 977, 1986 年 2 月.

[14] Moore, K., 《MIME（多用途互联网邮件扩展）第三部分：用于非 ASCII 文本的报文头扩展》, RFC 2047, 1996 年 11 月.

[15] Nebel, E. and L. Masinter, 《HTML 中基于表单的文件上传》, RFC 1867, 1995 年 11 月.

[16] Postel, J., 《简单邮件传输协议》, STD 10, RFC 821, 1982 年 8 月.

[17] Postel, J., 《媒体类型注册流程》, RFC 1590, 1996 年 11 月.

[18] Postel, J. and J. Reynolds, 《文件传输协议》, STD 9, RFC 959, 1985 年 10 月.

[19] Reynolds, J. and J. Postel, 《已分配编号》, STD 2, RFC 1700, 1994 年 10 月.

[20] Sollins, K. and L. Masinter, 《统一资源名称的功能需求》, RFC 1737, 1994 年 12 月.

[21] US-ASCII. 编码字符集——7 位美国信息交换标准代码（Coded Character Set - 7-Bit American Standard Code for Information Interchange）. 标准 ANSI X3.4-1986, ANSI, 1986.

[22] ISO-8859. 国际标准——信息处理—— 8 位单字节编码图形字符集—— 第 1 部分：拉丁字母表 1 号, ISO-8859-1:1987. 第 2 部分：拉丁字母表 2 号, ISO-8859-2, 1987. 第 3 部分：拉丁字母表 3 号, ISO-8859-3, 1988. 第 4 部分：拉丁字母表 4 号, ISO-8859-4, 1988. 第 5 部分：拉丁/西里尔字母表, ISO-8859-5, 1988. 第 6 部分：拉丁/阿拉伯字母表, ISO-8859-6, 1987. 第 7 部分：拉丁/希腊字母表, ISO-8859-7, 1987. 第 8 部分：拉丁/希伯来字母表, ISO-8859-8, 1988. 第 9 部分：拉丁字母表 5 号, ISO-8859-9, 1990.

[23] Meyers, J. and M. Rose, 《Content-MD5 头字段》, RFC 1864, 1995 年 10 月.

[24] Carpenter, B. and Y. Rekhter, 《重新编号尚需完善》, RFC 1900, 1996 年 2 月.

[25] Deutsch, P., 《GZIP 文件格式规范 4.3 版》, RFC 1952, 1996 年 5 月.

[26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. 《改善 HTTP 延迟》, Computer Networks and ISDN Systems, v. 28, pp. 25-35, 1995 年 12 月. 该文为 Proc. 2nd International WWW Conference '94: Mosaic and the Web（1994 年 10 月）论文的略修订版, 可见于 http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat ency.html.

[27] Joe Touch, John Heidemann, and Katia Obraczka. 《HTTP 性能分析》, <URL: http://www.isi.edu/touch/pubs/http-perf96/>, ISI Research Report ISI/RR-98-463, （原报告日期 1996 年 8 月）, USC/Information Sciences Institute, 1998 年 8 月.

[28] Mills, D., 《网络时间协议（第 3 版）规范、实现与分析》, RFC 1305, 1992 年 3 月.

[29] Deutsch, P., 《DEFLATE 压缩数据格式规范 1.3 版》, RFC 1951, 1996 年 5 月.

[30] S. Spero, 《HTTP 性能问题剖析》, http://sunsite.unc.edu/mdma-release/http-prob.html.

[31] Deutsch, P. and J. Gailly, 《ZLIB 压缩数据格式规范 3.3 版》, RFC 1950, 1996 年 5 月.

[32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, 《HTTP 的扩展：摘要访问认证》, RFC 2069, 1997 年 1 月.

[33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, 《超文本传输协议 HTTP/1.1》, RFC 2068, 1997 年 1 月.

[34] Bradner, S., 《RFC 中用于表示需求等级的关键词》, BCP 14, RFC 2119, 1997 年 3 月.

[35] Troost, R. and Dorner, S., 《在互联报文中传递表示信息： Content-Disposition 头》, RFC 1806, 1995 年 6 月.

[36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, 《HTTP 版本号的使用与解释》, RFC 2145, 1997 年 5 月. [jg639]

[37] Palme, J., 《通用互联网报文头》, RFC 2076, 1997 年 2 月. [jg640]

[38] Yergeau, F., 《UTF-8, 一种 Unicode 与 ISO-10646 的转换格式》, RFC 2279, 1998 年 1 月. [jg641]

[39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E., Lie, H., and C. Lilley. 《HTTP/1.1、CSS1 与 PNG 的网络性能影响》, Proceedings of ACM SIGCOMM '97, 法国戛纳, 1997 年 9 月. [jg642]

[40] Freed, N. and N. Borenstein, 《多用途互联网邮件扩展（MIME）第二部分：媒体类型》, RFC 2046, 1996 年 11 月. [jg643]

[41] Alvestrand, H., 《IETF 关于字符集与语言的政策》, BCP 18, RFC 2277, 1998 年 1 月. [jg644]

[42] Berners-Lee, T., Fielding, R. and L. Masinter, 《统一资源标识符（URI）：通用语法与语义》, RFC 2396, 1998 年 8 月. [jg645]

[43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., Sink, E. and L. Stewart, 《HTTP 认证：基本与摘要访问认证》, RFC 2617, 1999 年 6 月. [jg646]

[44] Luotonen, A., 《通过 Web 代理服务器隧道传输基于 TCP 的协议》, Work in Progress. [jg647]

[45] Palme, J. and A. Hopmann, 《聚合文档（如 HTML）的 MIME 电子邮件封装（MHTML）》, RFC 2110, 1997 年 3 月.

[46] Bradner, S., 《互联网标准过程第 3 版》, BCP 9, RFC 2026, 1996 年 10 月.

[47] Masinter, L., 《超文本咖啡壶控制协议（HTCPCP/1.0）》, RFC 2324, 1998 年 4 月 1 日.

[48] Freed, N. and N. Borenstein, 《多用途互联网邮件扩展（MIME）第五部分：一致性准则与示例》, RFC 2049, 1996 年 11 月.

[49] Troost, R., Dorner, S. and K. Moore, 《在互联报文中传递表示信息： Content-Disposition 头字段》, RFC 2183, 1997 年 8 月.

18 作者地址 (Authors' Addresses)

Roy T. Fielding Information and Computer Science University of California, Irvine Irvine, CA 92697-3425, USA

Fax: +1 (949) 824-1715 EMail: [email protected]

James Gettys World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA

Fax: +1 (617) 258 8682 EMail: [email protected]

Jeffrey C. Mogul Western Research Laboratory Compaq Computer Corporation 250 University Avenue Palo Alto, California, 94305, USA

EMail: [email protected]

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: [email protected]

Larry Masinter Xerox Corporation 3333 Coyote Hill Road Palo Alto, CA 94034, USA

EMail: [email protected]

Paul J. Leach Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA

EMail: [email protected]

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: [email protected]

19 Appendices

19.1 互联网媒体类型 message/http 与 application/http

除定义 HTTP/1.1 协议外, 本文档还作为互联网媒体类型 "message/http" 与 "application/http" 的规范。message/http 类型可用于封装单个 HTTP 请求或响应报文, 前提是它遵守所有 "message" 类型关于行长度与编码的 MIME 限制。 application/http 类型可用于封装一条由一个或多个 HTTP 请求或响应报文组成的流水线（不可混合穿插）。以下内容需向 IANA 注册 [17].

   Media Type name:         message
   Media subtype name:      http
   Required parameters:     none
   Optional parameters:     version, msgtype
    version: The HTTP-Version number of the enclosed message
             (e.g., "1.1"). If not present, the version can be
             determined from the first line of the body.
    msgtype: The message type -- "request" or "response". If not
             present, the type can be determined from the first
             line of the body.
   Encoding considerations: only "7bit", "8bit", or "binary" are
                            permitted
   Security considerations: none

   Media Type name:         application
   Media subtype name:      http
   Required parameters:     none
   Optional parameters:     version, msgtype
    version: The HTTP-Version number of the enclosed messages
             (e.g., "1.1"). If not present, the version can be
             determined from the first line of the body.
    msgtype: The message type -- "request" or "response". If not
             present, the type can be determined from the first
             line of the body.
   Encoding considerations: HTTP messages enclosed by this type
             are in "binary" format; use of an appropriate
             Content-Transfer-Encoding is required when
             transmitted via E-mail.
   Security considerations: none

19.2 Internet Media Type multipart/byteranges

当 HTTP 206（Partial Content, 部分内容）响应报文包含多个范围的内容（即响应一个针对多个不重叠范围的请求）时, 这些内容以 multipart（多部分）报文主体的形式传输。用于此目的的媒体类型称为 "multipart/byteranges".

multipart/byteranges 媒体类型包含两个或多个部分, 每个部分都有自己的 Content-Type 与 Content-Range 字段。必需的 boundary（边界）参数指定用于分隔每个主体的边界字符串。

   Media Type name:         multipart
   Media subtype name:      byteranges
   Required parameters:     boundary
   Optional parameters:     none
   Encoding considerations: only "7bit", "8bit", or "binary" are
                            permitted
   Security considerations: none

For example:

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

...the first range... --THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 7000-7999/8000

...the second range --THIS_STRING_SEPARATES--

  注:

  1) 在实体的第一个边界字符串之前, 可能存在额外的 CRLF.

  2) 尽管 RFC 2046 [40] 允许对边界字符串使用引号, 但一些既有实现对带引号
     的边界字符串处理不正确.

  3) 一些浏览器与服务器按照 byteranges 规范的早期草案编码, 使用了
     multipart/x-byteranges 这一媒体类型, 它与 HTTP/1.1 中记述的版本
     几乎兼容, 但并不完全兼容.

19.3 Tolerant Applications

尽管本文档规定了 HTTP/1.1 报文生成的要求, 但并非所有应用都能正确实现. 因此, 我们建议运行中的应用在偏差能够被无歧义解释时, 对这些偏差保持宽容.

客户端在解析 Status-Line（状态行）时应保持宽容, 服务器在解析 Request-Line （请求行）时同样应保持宽容. 特别是, 它们应接受字段之间任意数量的 SP 或 HT 字符, 即便事实上只需要单个 SP.

报文头字段的行终止符是 CRLF 序列. 不过, 我们建议应用在解析此类头字段时, 将单个 LF 识别为行终止符, 并忽略其前导 CR.

实体主体的字符集应标记为该主体内所用字符码的最小公分母; 但存在一个例外: 不为实体加标签, 优于用 US-ASCII 或 ISO-8859-1 标签为实体加标签. 见第 3.7.1 与 3.4.1 节.

关于日期解析与编码, 以及其他日期编码潜在问题的附加要求规则包括:

  - HTTP/1.1 客户端与缓存 SHOULD 假设一个看似在未来 50 年以上的 RFC-850
    日期事实上属于过去（这有助于解决 "year 2000", 千年虫问题）.

  - HTTP/1.1 实现 MAY 在内部将一个解析出的 Expires（过期）日期表示为
    早于其正确值, 但 MUST NOT 在内部将其表示为晚于正确值.

  - 所有与过期相关的计算 MUST 在 GMT 中完成. 本地时区 MUST NOT 影响年龄
    或过期时间的计算与比较.

  - 如果一个 HTTP 头字段错误地携带了 GMT 之外时区的日期值, 它 MUST 使用
    尽可能保守的转换方式转换为 GMT.

19.4 Differences Between HTTP Entities and RFC 2045 Entities

HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, RFC 2045 讨论的是邮件, 而 HTTP 具有一些与 RFC 2045 所描述内容不同的特性. 这些差异是经过精心选择的, 目的是优化二进制连接上的性能, 允许更自由地使用新媒体类型, 简化日期比较, 并承认一些早期 HTTP 服务器与客户端的做法.

本附录描述了 HTTP 与 RFC 2045 不同的具体方面. 面向严格 MIME 环境的代理与网关 SHOULD 知晓这些差异, 并在必要时提供适当的转换. 从 MIME 环境到 HTTP 的代理与网关同样需要知晓这些差异, 因为某些转换可能是必需的.

19.4.1 MIME-Version

HTTP 并非一个符合 MIME 的协议. 不过, HTTP/1.1 报文 MAY 包含一个单独的 MIME-Version 通用头字段, 用以表明构造该报文时所使用的 MIME 协议版本. 使用 MIME-Version 头字段, 即表明该报文完全符合 MIME 协议（如 RFC 2045[7] 所定义）. 代理/网关在将 HTTP 报文导出至严格 MIME 环境时, 负责确保（在可行的范围内）完全符合.

   MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

MIME 版本 "1.0" 是 HTTP/1.1 中使用的默认值. 然而, HTTP/1.1 报文的解析与语义由本文档而非 MIME 规范定义.

19.4.2 Conversion to Canonical Form

RFC 2045 [7] 要求互联网邮件实体在传输前转换为规范形式, 如 RFC 2049 [48] 第 4 节所述. 本文档第 3.7.1 节描述了通过 HTTP 传输时 "text" 媒体类型各子类型所允许的形式. RFC 2046 要求类型为 "text" 的内容以 CRLF 表示换行, 并禁止在换行序列之外使用 CR 或 LF;

而 HTTP 在通过自身传输报文时, 允许以 CRLF、裸 CR 或裸 LF 表示文本内容中的换行.

在可行的情况下, 从 HTTP 到严格 MIME 环境的代理或网关 SHOULD 将本文档第 3.7.1 节所述的 text 媒体类型内的所有换行, 转换为 RFC 2049 的 CRLF 规范形式. 但需注意, 这一转换可能因存在 Content-Encoding, 以及 HTTP 允许使用某些不以八位组 13 和 10 表示 CR 与 LF 的字符集（某些多字节字符集即如此）而变得复杂.

实现者应注意, 除非原始内容已处于规范形式, 否则转换会破坏应用于原始内容的任何密码学校验和. 因此, 对于 HTTP 中使用此类校验和的内容, 推荐采用规范形式.

19.4.3 Conversion of Date Formats

HTTP/1.1 使用一组受限的日期格式（第 3.3.1 节）, 以简化日期比较过程. 来自其他协议的代理与网关 SHOULD 确保报文中出现的任何 Date 头字段都符合 HTTP/1.1 的某一种格式, 并在必要时重写该日期.

19.4.4 Introduction of Content-Encoding

RFC 2045 不包含任何与 HTTP/1.1 的 Content-Encoding 头字段等价的概念. 由于它充当媒体类型的修饰符, 从 HTTP 到 MIME 兼容协议的代理与网关 MUST 在转发报文前, 要么修改 Content-Type 头字段的值, 要么对实体主体进行解码.（一些用于互联网邮件的 Content-Type 实验性应用曾使用媒体类型参数 ";conversions=<content-coding>" 来实现等同于 Content-Encoding 的功能. 但该参数并非 RFC 2045 的一部分.）

19.4.5 No Content-Transfer-Encoding

HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP client.

Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct format and encoding for safe transport on that protocol, where "safe

transport" is defined by the limitations of the protocol being used. Such a proxy or gateway SHOULD label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over the destination protocol.

19.4.6 Introduction of Transfer-Encoding

HTTP/1.1 引入了 Transfer-Encoding 头字段（第 14.41 节）. 代理/网关 MUST 在通过 MIME 兼容协议转发报文之前, 移除任何传输编码（transfer-coding）.

解码 "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 and Line Length Limitations

与 MHTML [45] 实现共享代码的 HTTP 实现, 需要知晓 MIME 的行长度限制. 由于 HTTP 没有此限制, HTTP 不对长行进行折叠. 通过 HTTP 传输的 MHTML 报文遵循 MHTML 的全部约定（包括行长度限制、折叠、规范化等）, 因为 HTTP 将所有报文主体作为负载传输（见第 3.7.2 节）, 并不解释其内容或其中可能包含的任何 MIME 头行.

19.5 Additional Features

RFC 1945 与 RFC 2068 记载了一些既有 HTTP 实现所使用的协议元素, 但这些元素在大多数 HTTP/1.1 应用中并未被一致且正确地支持. 建议实现者知晓这些特性, 但不能依赖它们在其他 HTTP/1.1 应用中存在, 也不能依赖与它们的互操作性. 其中一些

描述了提议的实验性特性, 另一些则描述了经实验性部署发现存在不足、如今已在基础 HTTP/1.1 规范中得到处理的特性.

来自 SMTP 与 MIME 的若干其他头字段（如 Content-Disposition 与 Title）也常被实现（见 RFC 2076 [37]）.

19.5.1 Content-Disposition

Content-Disposition 响应头字段被提议作为一种手段, 用于源服务器在用户请求将内容保存为文件时建议一个默认文件名. 这一用法源自 RFC 1806 [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 )

An example is

    Content-Disposition: attachment; filename="fname.ext"

接收用户代理 SHOULD NOT 理会 filename-parm 参数中出现的任何目录路径信息, 该参数是目前被认为适用于 HTTP 实现的唯一参数. 文件名 SHOULD 仅被视为一个终端组件.

如果在带有 application/octet-stream 内容类型的响应中使用此头字段, 其隐含建议是用户代理不应显示该响应, 而是直接进入 "save response as..."（将响应另存为...）对话框.

有关 Content-Disposition 的安全问题, 见第 15.5 节.

19.6 Compatibility with Previous Versions

强制符合先前版本, 超出了协议规范的范围. 然而, HTTP/1.1 在设计上刻意做到易于支持先前版本. 值得指出的是, 在编写本规范之时（1996 年）, 我们预计商业 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 Changes from HTTP/1.0

本节概述 HTTP/1.0 与 HTTP/1.1 版本之间的主要差异.

19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses

要求客户端与服务器支持 Host 请求头, 在 HTTP/1.1 请求中缺少 Host 请求头（第 14.23 节）时报错, 以及接受绝对 URI（第 5.1.2 节）, 是本课规范定义的最为重要的变更之一.

较早的 HTTP/1.0 客户端假定 IP 地址与服务器之间为一一对应关系; 当时除请求所指向的 IP 地址外, 没有其他既定机制来区分请求的目标服务器. 一旦较旧的 HTTP 客户端不再普遍, 上述变更将使互联网能够从单一 IP 地址支撑多个网站, 从而极大简化大型运行中的 Web 服务器——这类服务器因向单一主机分配大量 IP 地址而产生了严重问题. 互联网还将能够收回那些纯粹为了允许在根级 HTTP URL 中使用专用域名而分配的 IP 地址. 鉴于 Web 的增长速度以及已部署服务器的数量, 至关重要的一点是 HTTP 的所有实现（包括对既有 HTTP/1.0 应用的更新）都必须正确实现这些要求:

important that all implementations of HTTP (including updates to existing HTTP/1.0 applications) correctly implement these requirements:

  - 客户端与服务器 MUST 都支持 Host 请求头.

  - 发送 HTTP/1.1 请求的客户端 MUST 发送 Host 头.

  - 若 HTTP/1.1 请求未包含 Host 请求头, 服务器 MUST 报告 400（Bad Request,
    错误请求）错误.

  - 服务器 MUST 接受绝对 URI.

19.6.2 Compatibility with HTTP/1.0 Persistent Connections

某些客户端与服务器可能希望与 HTTP/1.0 客户端和服务器中一些既有的持久连接实现保持兼容. 在 HTTP/1.0 中, 持久连接是显式协商的, 因为它并非默认行为. HTTP/1.0 对持久连接的实验性实现存在缺陷, 而 HTTP/1.1 中的新机制正是为纠正这些问题而设计的. 问题症结在于: 一些既有的 1.0 客户端可能向不理解 Connection 的代理服务器发送 Keep-Alive, 代理随后会错误地将其转发给下一个入站服务器, 后者会建立 Keep-Alive 连接, 导致一个挂起的 HTTP/1.0 代理一直等待响应关闭. 结果是, 必须阻止 HTTP/1.0 客户端在与代理通信时使用 Keep-Alive.

然而, 与代理通信正是持久连接最重要的用途, 因此上述禁止显然不可接受. 于是, 我们需要另一种机制来表示期望使用持久连接, 该机制即便与忽略 Connection 的旧代理通信也是安全的. 对 HTTP/1.1 报文而言, 持久连接是默认行为; 我们引入新的关键字（Connection: close）来声明非持久. 见第 14.10 节.

持久连接的原始 HTTP/1.0 形式（Connection: Keep-Alive 与 Keep-Alive 头）记载于 RFC 2068. [33]

19.6.3 Changes from RFC 2068

This specification has been carefully audited to correct and disambiguate key word usage; RFC 2068 had many problems in respect to the conventions laid out in RFC 2119 [34].

Clarified which error code should be used for inbound server failures (e.g. DNS failures). (Section 10.5.5).

CREATE 存在竞争条件, 要求在首次创建资源时发送 Etag. （第 10.2.2 节）

Content-Base 已从规范中删除: 它未被广泛实现, 且在缺乏健壮扩展机制的情况下, 没有简单, 安全的方式引入它. 此外, MHTML [45] 中以相似但不完全相同的方式使用了它.

传输编码（Transfer-coding）与报文长度之间的相互作用, 需要在使用分块编码时精确修正（以允许可能非自定界的传输编码）; 厘清报文长度究竟如何计算十分重要. （第 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16 节）

A content-coding of "identity" was introduced, to solve problems discovered in caching. (section 3.5)

Quality Values of zero should indicate that "I don't want something" 以便客户端能够拒绝某个表示（representation）. （第 3.9 节）

HTTP 版本号的使用与解释已由 RFC 2145 澄清. 要求代理将请求升级到其所支持的最高协议版本, 以应对在 HTTP/1.0 实现中发现的问题. （第 3.1 节）

引入字符集通配（wildcarding）, 以避免 accept 头中字符集名称的爆炸式增长. （第 14.2 节）

HTTP/1.1 的 Cache-Control 模型中遗漏了一个情形; 引入 s-maxage 以补全这一缺失情形. （第 13.4, 14.8, 14.9, 14.9.3 节）

Cache-Control 的 max-age 指令此前未针对响应正确定义. （第 14.9.3 节）

在某些情况下, 服务器（尤其是代理）并不知道响应的完整长度, 却能够服务于字节范围请求. 因此我们需要一种机制, 允许 content-range 不指示报文完整长度的字节范围. （第 14.16 节）

若总是返回全部元数据, 范围请求响应会变得非常冗长; 通过允许服务器仅在 206 响应中发送所需头, 可避免此问题. （第 10.2.7, 13.5.3 与 14.27 节）

Fix problem with unsatisfiable range requests; there are two cases: syntactic problems, and range doesn't exist in the document. The 416 status code was needed to resolve this ambiguity needed to indicate an error for a byte range request that falls outside of the actual contents of a document. (Section 10.4.17, 14.16)

重写了报文传输的要求, 以使实现者更难出错——因为此处的错误后果可能对互联网产生显著影响, 同时处理了以下问题:

将 "HTTP/1.1 或更高版本" 改为 "HTTP/1.1", 用于那些原本错误地对未来
     版本 HTTP/1.x 实现的行文施加要求之处.

明确应是 user-agent（用户代理）重试请求, 而非泛指 "客户端".

将 "客户端忽略意外的 100（Continue）响应, 代理转发 100 响应" 的要求,
     转化为针对 1xx 响应的通用要求.

修改了一些 TCP 特定的措辞, 以更清晰地表明 HTTP 也可用非 TCP 传输.

要求源服务器 MUST NOT 在发送所需的 100（Continue）响应前等待请求主体.

允许（而非要求）服务器在已看到部分请求主体时省略 100（Continue）.

允许服务器防范拒绝服务攻击与有缺陷的客户端.

此变更新增了 Expect 头与 417 状态码. 报文传输要求的修正位于第 8.2, 10.4.18, 8.1.2.2, 13.11 与 14.20 节.

代理应能在适当时添加 Content-Length. （第 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 节）Warning 还需作为通用头来使用, 因为 PUT 或其他方法可能在请求中需要它.

传输编码（Transfer-coding）曾存在显著问题, 尤其是与分块编码的相互作用. 解决方案是让传输编码与内容编码一样成为完备的机制. 这涉及新增一个传输编码的 IANA 注册表（独立于内容编码）, 一个新的头字段（TE）, 以及将来启用尾部头（trailer headers）. 传输编码能带来显著的性能收益, 因此值得修正 [39]. TE 还解决了另一个因认证尾部头, 分块编码与 HTTP/1.0 客户端之间的相互作用而可能产生的, 隐蔽的向下互操作问题. （第 3.6, 3.6.1 与 14.39 节）

PATCH, LINK, UNLINK 方法在先前版本的本规范中已有定义, 但并未被广泛实现. 见 RFC 2068 [33].

Alternates, Content-Version, Derived-From, Link, URI, Public 与 Content-Base 头字段在先前版本的本规范中已有定义, 但并未被广泛实现. 见 RFC 2068 [33].

20 Index

Please see the PostScript version of this RFC for the INDEX.

Full Copyright Statement

本文档及其译文可被复制并提供给他人; 对本文档进行注释, 解释或辅助实现的衍生作品, 可在不受任何限制的情况下全部或部分地准备, 复制, 出版与分发, 前提是所有此类副本与衍生作品均包含上述版权声明与本段文字. 然而, 本文档本身不得以任何方式被修改（例如移除版权声明或对互联网协会及其他互联网组织的引用）, 除非是为制定互联网标准所需（此时须遵循互联网标准过程中定义的版权程序）, 或为将其翻译为英语之外的语言所需.

上述授予的有限许可是永久性的, 不会被互联网协会或其继承者或受让者撤销.

本文档及其中所包含的信息按 "AS IS"（原样）基础提供, 互联网协会与互联网工程任务组声明放弃所有明示或默示的担保, 包括但不限于关于使用本文档信息不侵犯任何权利, 以及关于适销性或特定用途适用性的任何默示担保.

致谢

RFC 编辑职能的经费目前由互联网协会提供.