1. 引言
超文本传输协议 (Hypertext Transfer Protocol, HTTP) 是一种无状态的、应用层的请求/响应协议, 它使用可扩展的语义和自描述的消息载荷, 以便与基于网络的超文本信息系统进行灵活交互. 本文档是由多份文档共同构成的 HTTP/1.1 规范系列中的第一份:
- "消息语法与路由" (本文档)
- "语义与内容" [RFC7231]
- "条件请求" [RFC7232]
- "范围请求" [RFC7233]
- "缓存" [RFC7234]
- "认证" [RFC7235]
本 HTTP/1.1 规范废弃了 RFC 2616 以及 (关于 HTTP 版本管理的) RFC 2145. 本规范还更新了先前在 RFC 2817 中定义的、使用 CONNECT 建立隧道的用法, 并定义了在 RFC 2818 中曾以非正式方式描述的 "https" URI 方案.
HTTP 是面向信息系统的一种通用接口协议. 它的设计目标是: 通过向客户端呈现一个与所提供资源类型无关的统一接口, 把服务实现方式的细节隐藏起来. 同样, 服务器也不需要了解每个客户端的目的: HTTP 请求可以被孤立地看待, 而不必与某一特定类型的客户端或某个预先确定的应用步骤序列相关联. 其结果是, 该协议可以在许多不同场景下被有效使用, 并且其实现可以随时间独立演进.
HTTP 还被设计为一种中介协议 (intermediation protocol), 用于与非 HTTP 信息系统之间双向转换通信. HTTP 代理和网关可以把多种多样的协议转换成一种超文本格式, 从而让客户端能以与访问 HTTP 服务相同的方式查看和操作这些替代信息服务.
这种灵活性带来的一个后果是: 协议无法依据接口背后发生的事情来定义. 相反, 我们只能定义通信的语法、所接收通信的意图, 以及接收方应当表现的行为. 如果把通信孤立地看待, 那么成功的动作就应当体现在服务器所提供的可观察接口的相应变化上. 然而, 由于多个客户端可能并行行动, 而且目的可能相互冲突, 我们不能要求这类变化在单次响应的范围之外也可被观察到.
本文档描述了 HTTP 中使用或提及的各种架构元素, 定义了 "http" 与 "https" URI 方案, 描述了整体网络运行与连接管理, 并定义了 HTTP 消息的分帧 (framing) 与转发要求. 我们的目标是定义所有与消息语义无关、但 HTTP 消息处理所必需的机制, 从而给出消息解析器和消息转发中间方的完整要求集合.
1.1. 要求记法
本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按 [RFC2119] 所述进行解释.
一致性判定标准以及关于错误处理的考量见第 2.5 节.
1.2. 语法记法
本规范使用 [RFC5234] 的增强巴科斯范式 (Augmented Backus-Naur Form, ABNF) 记法, 并采用第 7 节所定义的一种列表扩展: 它允许用 # 运算符 (类似于 * 运算符表示重复的方式) 来紧凑地定义以逗号分隔的列表. 附录 B 给出了把所有列表运算符展开为标准 ABNF 记法之后的完整文法.
以下核心规则按引用方式纳入本规范, 其定义见 [RFC5234] 附录 B.1: ALPHA (字母)、CR (回车)、CRLF (CR LF)、CTL (控制字符)、DIGIT (十进制数字 0-9)、DQUOTE (双引号)、HEXDIG (十六进制数字 0-9/A-F/a-f)、HTAB (水平制表符)、LF (换行)、OCTET (任意 8 位数据序列)、SP (空格) 和 VCHAR (任意可见的 [USASCII] 字符).
按惯例, 以 "obs-" 为前缀的 ABNF 规则名表示因历史原因而保留的 "过时" 文法规则.