1. Introduction (简介)
1.1. Purpose (目的)
超文本传输协议 (Hypertext Transfer Protocol, HTTP) 是一系列无状态 (Stateless) 的、应用层 (Application-Level) 的请求/响应协议 (Request/Response Protocols), 这些协议共享通用接口 (Generic Interface)、可扩展语义 (Extensible Semantics) 和自描述消息 (Self-Descriptive Messages), 以实现与基于网络的超文本信息系统的灵活交互.
HTTP 通过向客户端呈现统一接口 (Uniform Interface) 来隐藏服务实现的细节, 该接口独立于所提供资源的类型. 同样, 服务器无需了解每个客户端的目的: 请求可以被独立地考虑, 而不是与特定类型的客户端或预定的应用步骤序列相关联. 这允许通用实现在许多不同的上下文中有效使用, 降低交互复杂性, 并实现随时间独立演进.
HTTP 也被设计为中介协议 (Intermediation Protocol), 其中代理 (Proxies) 和网关 (Gateways) 可以将非HTTP信息系统转换为更通用的接口.
这种灵活性的一个后果是, 协议无法根据接口背后发生的事情来定义. 相反, 我们只能定义通信的语法 (Syntax of Communication)、接收到的通信的意图 (Intent) 以及接收方的预期行为 (Expected Behavior). 如果单独考虑通信, 那么成功的操作应该反映在服务器提供的可观察接口的相应变化中. 但是, 由于多个客户端可能并行行动, 甚至可能目的相反, 我们无法要求这些变化在单个响应范围之外是可观察的.
1.2. History and Evolution (历史和演进)
自1990年引入以来, HTTP一直是万维网 (World Wide Web) 的主要信息传输协议. 它最初是一个简单的低延迟请求机制, 只有一个方法 (GET) 用于请求传输由给定路径名标识的假定超文本文档. 随着Web的发展, HTTP被扩展为在消息中封装请求和响应, 使用类似MIME的媒体类型 (Media Types) 传输任意数据格式, 并通过中间人 (Intermediaries) 路由请求. 这些协议最终被定义为HTTP/0.9和HTTP/1.0 (参见 [HTTP/1.0]).
HTTP/1.1的设计旨在改进协议特性, 同时保持与现有基于文本的消息语法的兼容性, 提高其在互联网上的互操作性 (Interoperability)、可扩展性 (Scalability) 和健壮性 (Robustness). 这包括针对固定和动态 (分块, Chunked) 内容的基于长度的数据定界符 (Length-Based Data Delimiters)、用于内容协商 (Content Negotiation) 的一致框架、用于条件请求 (Conditional Requests) 的不透明验证器 (Opaque Validators)、用于更好缓存一致性的缓存控制 (Cache Controls)、用于部分更新的范围请求 (Range Requests) 以及默认持久连接 (Persistent Connections). HTTP/1.1于1995年引入, 并于1997年在标准跟踪 (Standards Track) 上发布 [RFC2068], 于1999年修订 [RFC2616], 并于2014年再次修订 ([RFC7230] 到 [RFC7235]).
HTTP/2 ([HTTP/2]) 在现有TLS和TCP协议之上引入了多路复用会话层 (Multiplexed Session Layer), 用于交换并发HTTP消息, 具有高效的字段压缩 (Field Compression) 和服务器推送 (Server Push) 功能. HTTP/3 ([HTTP/3]) 通过使用QUIC作为UDP上的安全多路复用传输而不是TCP, 为并发消息提供了更大的独立性.
所有三个主要HTTP版本都依赖于本文档定义的语义. 它们没有相互废止, 因为每个版本根据使用上下文都有特定的优势和局限性. 实现应该为其特定上下文选择最合适的传输和消息语法.
本次HTTP修订将语义 (本文档) 和缓存 ([CACHING]) 的定义与当前的HTTP/1.1消息语法 ([HTTP/1.1]) 分离, 以允许每个主要协议版本独立发展, 同时引用相同的核心语义.
1.3. Core Semantics (核心语义)
HTTP提供了一个统一接口, 用于与资源 (Resource, 第3.1节) 交互 - 无论其类型、性质或实现如何 - 通过发送操纵或传输表示 (Representations, 第3.2节) 的消息.
每条消息要么是请求 (Request), 要么是响应 (Response). 客户端构造传达其意图的请求消息, 并将这些消息路由到已识别的源服务器 (Origin Server). 服务器监听请求, 解析接收到的每条消息, 根据已识别的目标资源 (Target Resource) 解释消息语义, 并用一个或多个响应消息响应该请求. 客户端检查接收到的响应, 查看其意图是否已执行, 根据接收到的状态码 (Status Codes) 和内容确定下一步做什么.
HTTP语义包括每个请求方法 (第9节) 定义的意图、可能在请求头字段 (Request Header Fields) 中描述的对这些语义的扩展、描述响应的状态码 (第15节), 以及可能在响应字段中给出的其他控制数据和资源元数据 (Resource Metadata).
语义还包括描述接收方如何解释内容的表示元数据 (Representation Metadata)、可能影响内容选择的请求头字段, 以及统称为"内容协商" (Content Negotiation, 第12节) 的各种选择算法.
1.4. Specifications Obsoleted by This Document (本文档废止的规范)
| 标题 | 参考 | 参见 |
|---|---|---|
| HTTP Over TLS | [RFC2818] | B.1 |
| HTTP/1.1 Message Syntax and Routing [*] | [RFC7230] | B.2 |
| HTTP/1.1 Semantics and Content | [RFC7231] | B.3 |
| HTTP/1.1 Conditional Requests | [RFC7232] | B.4 |
| HTTP/1.1 Range Requests | [RFC7233] | B.5 |
| HTTP/1.1 Authentication | [RFC7235] | B.6 |
| HTTP Status Code 308 (Permanent Redirect) | [RFC7538] | B.7 |
| HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields | [RFC7615] | B.8 |
| HTTP Client-Initiated Content-Encoding | [RFC7694] | B.9 |
表 1
[*] 本文档仅废止RFC 7230中独立于HTTP/1.1消息语法和连接管理的部分; RFC 7230的其余部分由"HTTP/1.1" [HTTP/1.1]废止.