1. Introduction (简介)
1.1 Purpose (目的)
超文本传输协议 (Hypertext Transfer Protocol, HTTP) 是一个应用层协议，用于分布式、协作式、超媒体信息系统。HTTP 自 1990 年以来一直被万维网全球信息倡议使用。HTTP 的第一个版本，称为 HTTP/0.9，是一个简单的协议，用于通过互联网进行原始数据传输。RFC 1945 [6] 定义的 HTTP/1.0 改进了协议，允许消息采用类似 MIME 的消息格式，包含关于传输数据的元信息以及对请求/响应语义的修饰符。然而，HTTP/1.0 没有充分考虑分层代理、缓存、持久连接需求或虚拟主机的影响。此外，大量不完整实现的应用程序自称为"HTTP/1.0"，这使得协议版本更改成为必要，以便两个通信应用程序能够确定彼此的真实能力。
本规范定义了被称为"HTTP/1.1"的协议。该协议比 HTTP/1.0 包含更严格的要求，以确保其特性的可靠实现。
实用的信息系统需要的功能不仅仅是简单的检索，还包括搜索、前端更新和注释。HTTP 允许开放式的方法和头字段集合，用于指示请求的目的 [47]。它建立在统一资源标识符 (Uniform Resource Identifier, URI) [3] 提供的引用规范之上，作为位置 (URL) [4] 或名称 (URN) [20]，用于指示要应用方法的资源。消息以类似于互联网邮件 [9] 使用的格式传递，由多用途互联网邮件扩展 (Multipurpose Internet Mail Extensions, MIME) [7] 定义。
HTTP 也被用作用户代理与代理/网关之间通信的通用协议，用于连接其他互联网系统，包括由 SMTP [16]、NNTP [13]、FTP [18]、Gopher [2] 和 WAIS [10] 协议支持的系统。通过这种方式，HTTP 允许对来自不同应用程序的可用资源进行基本的超媒体访问。
1.2 Requirements (要求)
本文档中的关键词"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"和"OPTIONAL"应按 RFC 2119 [34] 中的描述进行解释。
如果实现未能满足其实现的协议的一个或多个 MUST 或 REQUIRED 级别要求，则该实现不合规。满足其协议的所有 MUST 或 REQUIRED 级别要求以及所有 SHOULD 级别要求的实现被称为"无条件合规" (unconditionally compliant)；满足所有 MUST 级别要求但不满足其协议的所有 SHOULD 级别要求的实现被称为"有条件合规" (conditionally compliant)。
1.3 Terminology (术语)
本规范使用许多术语来指代 HTTP 通信中参与者和对象所扮演的角色。
connection (连接) 为通信目的在两个程序之间建立的传输层虚拟电路。
message (消息) HTTP 通信的基本单元，由符合第 4 节中定义的语法的结构化八位字节序列组成，并通过连接传输。
request (请求) HTTP 请求消息，如第 5 节所定义。
response (响应) HTTP 响应消息，如第 6 节所定义。
resource (资源) 可以由 URI 标识的网络数据对象或服务，如第 3.2 节所定义。资源可能以多种表示形式提供（例如多种语言、数据格式、大小和分辨率）或以其他方式变化。
entity (实体) 作为请求或响应有效负载传输的信息。实体由实体头字段形式的元信息和实体主体形式的内容组成，如第 7 节所述。
representation (表示) 响应中包含的、受内容协商约束的实体，如第 12 节所述。特定响应状态可能存在多个关联的表示。
content negotiation (内容协商) 在服务请求时选择适当表示的机制，如第 12 节所述。任何响应中的实体表示都可以协商（包括错误响应）。
variant (变体) 资源在任何给定时刻可能有一个或多个与之关联的表示。这些表示中的每一个都被称为"变体" (variant)。使用术语"变体"并不一定意味着资源受内容协商的约束。
client (客户端) 为发送请求而建立连接的程序。
user agent (用户代理) 发起请求的客户端。这些通常是浏览器、编辑器、网络蜘蛛（web-traversing robots）或其他最终用户工具。
server (服务器) 接受连接以通过发送响应来服务请求的应用程序。任何给定的程序都可能既是客户端又是服务器；我们使用这些术语仅指程序在特定连接中执行的角色，而不是指程序的一般能力。同样，任何服务器都可以充当源服务器、代理、网关或隧道，根据每个请求的性质切换行为。
origin server (源服务器) 给定资源驻留或将要创建的服务器。
proxy (代理) 一个中介程序，既充当服务器又充当客户端，目的是代表其他客户端发出请求。请求在内部处理或通过可能的翻译传递到其他服务器。代理必须 (MUST) 实现本规范的客户端和服务器要求。"透明代理" (transparent proxy) 是除了代理身份验证和标识所需的内容之外不修改请求或响应的代理。"非透明代理" (non-transparent proxy) 是为了向用户代理提供某些附加服务而修改请求或响应的代理，例如组注释服务、媒体类型转换、协议简化或匿名过滤。除非明确声明透明或非透明行为，否则 HTTP 代理要求适用于两种类型的代理。
gateway (网关) 充当某些其他服务器的中介的服务器。与代理不同，网关接收请求时就像它是所请求资源的源服务器；请求客户端可能不知道它正在与网关通信。
tunnel (隧道) 充当两个连接之间盲中继的中介程序。一旦激活，隧道不被视为 HTTP 通信的一方，尽管隧道可能由 HTTP 请求发起。当中继连接的两端都关闭时，隧道不再存在。
cache (缓存) 程序的响应消息本地存储以及控制其消息存储、检索和删除的子系统。缓存存储可缓存的响应，以减少未来等效请求的响应时间和网络带宽消耗。任何客户端或服务器都可能包含缓存，但充当隧道的服务器不能使用缓存。
cacheable (可缓存) 如果允许缓存存储响应消息的副本以用于回答后续请求，则响应是可缓存的。用于确定 HTTP 响应是否可缓存的规则在第 13 节中定义。即使资源是可缓存的，对于特定缓存是否应该缓存它可能还有其他约束。
first-hand (第一手) 如果响应来自源服务器，可能通过一个或多个代理，则该响应是第一手的。如果响应的有效性已由源服务器检查，则该响应也是第一手的。
explicit expiration time (显式过期时间) 源服务器打算实体在此时间之后不再被缓存返回而不进行进一步验证的时间。
heuristic expiration time (启发式过期时间) 缓存在缺少显式过期时间的情况下分配的过期时间。
age (年龄) 响应的年龄是自源服务器发送响应（或成功验证响应）以来的时间。
freshness lifetime (新鲜度生命周期) 响应生成到其过期时间之间的时间长度。
fresh (新鲜) 如果响应的年龄尚未超过其新鲜度生命周期，则该响应是新鲜的。
stale (陈旧) 如果响应的年龄已超过其新鲜度生命周期，则该响应是陈旧的。
semantically transparent (语义透明) 当缓存的使用对于请求客户端或源服务器都不影响时，缓存的行为是语义透明的，除了改进性能之外。当缓存以语义透明的方式运行时，客户端收到的响应与直接从源服务器发送的响应完全相同（除了跳段 (hop-by-hop) 头字段），缓存不会影响后续请求的处理。
validator (验证器) 协议元素（例如实体标签或 Last-Modified 时间），用于确定缓存条目是否是实体的等效副本。
upstream/downstream (上游/下游) 上游和下游描述消息流：所有消息都从上游流向下游。
inbound/outbound (入站/出站) 入站和出站是指相对于请求的请求和响应路径："入站"表示"朝向源服务器"，"出站"表示"朝向用户代理"。
1.4 Overall Operation (总体操作)
HTTP 协议是一个请求/响应协议。客户端向服务器发送请求，请求采用请求方法、URI 和协议版本的形式，后跟包含请求修饰符、客户端信息和可能的主体内容的类 MIME 消息，通过连接传输。服务器以状态行响应，包括消息的协议版本和成功或错误代码，后跟包含服务器信息、实体元信息和可能的实体主体内容的类 MIME 消息。大多数 HTTP 通信由用户代理发起，并且包括对源服务器上某个资源的请求。在最简单的情况下，这可以通过用户代理 (UA) 和源服务器 (O) 之间的单个连接 (v) 来完成。
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
更复杂的情况发生在请求/响应链中存在一个或多个中介时。有三种常见形式的中介：代理 (proxy)、网关 (gateway) 和隧道 (tunnel)。代理是转发代理，根据 URI 的绝对形式接收请求，重写全部或部分消息，并通过 URI 标识向服务器转发重新格式化的请求。网关是接收代理，充当其他服务器的上层，如果需要，可以将请求翻译为底层服务器的协议。隧道充当两个连接之间的中继点，不更改消息；当通信需要通过中介（例如防火墙等）进行时，即使中介无法理解消息的内容，也会使用隧道。
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
上图显示了用户代理和源服务器之间的三个中介（A、B 和 C）。通过整个请求/响应链的消息使用 HTTP 通信选项的传递机制来确定连接的参数。
任何不充当隧道的一方都可以使用缓存来满足请求。缓存对请求/响应链的影响取决于链中可能拦截请求或响应的各种缓存的缓存要求。缓存行为和可缓存响应在第 13 节中定义。
实际上，互联网上和组织内部有各种架构模式的配置。例如，"全国访问提供商"通常使用大型代理缓存，以便多个用户代理可以通过同一条请求链访问源服务器。另一个常见的配置是"反向代理"缓存，位于组织的主机名下，但由其客户端控制或某个第三方控制。反向代理缓存对用户代理是透明的，但通常由网络提供商管理以节省跨越网络的流量。
HTTP 通信通常发生在 TCP/IP 连接上。默认端口是 TCP 80 [19]，但也可以使用其他端口。这不排除在互联网或其他网络上的其他协议上实现 HTTP。HTTP 仅假定可靠的传输；任何提供此类保证的协议都可以使用；HTTP/1.1 请求和响应结构到给定传输协议的数据单元的映射超出了本规范的范围。
在 HTTP/1.0 中，大多数实现在每次请求/响应交换后都会关闭连接。在 HTTP/1.1 中，机制允许同一连接用于多次请求/响应交换，如第 8.1 节所述，使用"持久连接" (persistent connections)。