1.1 目的

超文本传输协议（HTTP）是一个分布式、协作式、超媒体信息系统的应用级协议。自 1990 年以来，HTTP 一直被万维网全球信息倡议所使用。HTTP 的第一个版本，被称为 HTTP/0.9，是一个简单的协议，用于在互联网上传输原始数据。由 RFC1945 [6] 定义的 HTTP/1.0 改进了协议，允许消息采用类似MIME的格式，包含关于传输数据的元信息和关于请求/响应语义的修改器。然而，HTTP/1.0 并没有充分考虑到分层代理、缓存、持久连接的需要或虚拟主机的影响。此外，不完全实现的自称为 “HTTP/1.0” 的应用程序的激增，使得协议版本的改变成为必要，以便两个通信的应用程序能够确定对方的真实能力。

本规范定义了被称为 “HTTP/1.1 “的协议。该协议包括比 HTTP/1.0 更严格的要求，以确保其功能的可靠实施。

实用的信息系统需要比简单检索更多的功能，包括搜索、前端更新和注释。HTTP 允许一套开放式的方法和头，表明请求的目的 [47]。它建立在统一资源标识符（URI）[3] 所提供的参考学科上，作为一个位置（URL）[4] 或名称（URN）[20]，用于指示一个方法所要应用的资源。消息以类似于多用途互联网邮件扩展（MIME）[7] 所定义的互联网邮件 [9] 的格式传递。

HTTP 也被用作用户代理和代理/网关与其他互联网系统之间通信的通用协议，包括那些由SMTP [16]、NNTP [13]、FTP [18]、Gopher [2] 和 WAIS [10] 协议支持的协议。通过这种方式，HTTP 允许基本的超媒体访问来自不同应用程序的可用资源。

1.2 规定

本文档中的关键词 “MUST”、”MUST NOT”、”REQUIRED”、”SHALL”、”SHALL NOT”、”SHOULD NOT”、”RECOMMENDED”、”MAY “和 “OPTIONAL “应按照 RFC2119 [34] 中的描述来解释。

如果一个实现不能满足它所实现的协议的一个或多个 “MUST” 或 “REQUIRED” 级别的要求，那么它就是不合规的。满足所有 “MUST” 或 “REQUIRED” 级别和所有 “SHOULD” 级别的协议要求的实现被称为 “无条件符合”；满足所有 “MUST “级别要求但不满足所有 “SHOULD” 级别要求的协议被称为 “有条件符合”。

1.3 术语

本规范使用一些术语来指代 HTTP 通信的参与者和对象所扮演的角色。

connection（连接）
在两个程序之间为通信目的建立的传输层虚拟电路。

message（报文）
HTTP通信的基本单位，由符合第 4 节定义的语法的八位数的结构化序列组成，通过连接传输。通过 connection 进行传输。

request（请求）
一个 HTTP 请求消息，如第 5 节所定义。

response（响应）
一个 HTTP 请求消息，如第 6 节所定义。

resource（资源）
如第 3.2 节所定义的，可由 URI 识别的网络数据对象或服务。资源可能有多种表现形式（如多种语言、数据格式、大小和分辨率）或以其他方式变化。

entity（实体）
作为请求或响应的有效载荷传输的信息。一个实体由实体头字段形式的元信息和实体主体形式的内容组成，如第 7 节所述。

representation（表示）
包含在响应中的实体，该实体需要进行内容协商，如第 12 节所述。可能存在与特定响应状态相关的多个表示。

content negotiation（内容协商）
在为请求提供服务时选择适当的表示方法的机制，如第 12 节所述。任何响应中的实体表示都可以协商（包括错误响应）。

variant（变体）
在任何给定时刻，资源可能有一个或多个与其相关联的表示。 这些表示中的每一个都被称为“变体”。 使用术语“变体”并不一定意味着资源受内容协商的影响。

client（客户端）
一个为发送请求而建立连接的程序。

user agent（用户代理）
发起请求的客户端。这些通常是浏览器、编辑器、爬虫（网络穿越机器人）或其他终端用户工具。

server（服务端）
一个接受连接的应用程序，以便通过送回响应来服务请求。任何给定的程序都可能既是客户又是服务器；我们对这些术语的使用仅指该程序在特定连接中所扮演的角色，而不是指该程序的一般能力。同样，任何服务器都可以充当原点服务器、代理、网关或隧道，根据每个请求的性质转换行为。

origin server（源站服务器）
给定资源所在的或将被创建的服务器。

proxy（代理）
一个中介程序，它既是服务器又是客户，目的是代表其他客户发出请求。请求在内部提供服务，或通过将其传递给其他服务器，并可能进行翻译。代理必须同时实现本规范的客户和服务器要求。一个 “透明的代理” 是一个代理，除了代理认证和识别所需的内容外，不修改请求或响应。”非透明代理” 是指修改请求或响应以向用户代理提供某些附加服务的代理，例如组注释服务、媒体类型转换、协议减少或匿名过滤。除非明确说明透明或非透明的行为，否则 HTTP 代理要求适用于这两种类型的代理。

gateway（网关）
一个充当其他服务器的中介的服务器。与代理不同，网关接收请求时，就像它是被请求资源的源服务器一样；请求的客户可能不知道它在与网关通信。

tunnel（隧道）
一个中介程序，在两个连接之间充当盲目的中继。一旦激活，隧道就不被认为是 HTTP 通信的一方，尽管隧道可能是由一个 HTTP 请求发起的。当中继连接的两端都关闭时，隧道就不存在了。

cache（缓存）
如果允许缓存存储响应信息的副本以用于回答后续请求，那么响应就是可缓存的。确定 HTTP 响应的可缓冲性的规则在第 13 节中定义。即使资源是可缓存的，对于缓存是否可以为特定的请求使用缓存的副本也可能有额外的限制。

first-hand（第一手）
如果响应直接来自源服务器并且没有不必要的延迟（可能通过一个或多个代理），则响应是第一手的。 如果刚刚直接与源服务器检查了响应的有效性，则响应也是第一手的。

explicit expiration time（明确的过期时间）
源服务器打算在没有进一步验证的情况下不再由缓存返回实体的时间。

heuristic expiration time（启发式过期时间）
当没有明确的过期时间可用时，由缓存分配的过期时间。

age
响应的 age 是自它被源服务器发送或成功验证以来的时间。

freshness lifetime（保鲜期）
生成响应与其到期时间之间的时间长度。

fresh（新鲜的）
如果响应的 age 尚未超过其保鲜期，则该响应是新鲜的。

stale（陈旧的）
如果响应的 age 已超过其保鲜期，则该响应是陈旧的。

semantically transparent（语义透明）
缓存以 “语义透明” 的方式来处理一个特定的响应，当它的使用既不影响请求的客户端，也不影响源服务器，只是为了提高性能。当一个缓存在语义上是透明的，客户端收到的响应（除了逐跳头）与它在原服务器直接处理其请求时收到的响应完全一样。

validator（验证器）
一个协议元素（例如，一个实体标签或最后修改时间），用于找出一个缓存条目是否是一个实体的等效副本。

upstream/downstream（上游/下游）
上游和下游描述了消息的流动：所有的消息都从上游流向下游。信息从上游流向下游。

inbound/outbound（入站/出站）
入站和出站指的是消息的请求和响应路径。”入站” 是指 “向原服务器移动”，而 “出站” 是指 “向用户代理移动”。

1.4 整体运作

HTTP 协议是一个请求/响应协议。客户端以请求方法、URI 和协议版本的形式向服务器发送请求，随后是一个类似 MIME 的消息，包含请求修饰语、客户信息和可能的主体内容，通过与服务器连接。服务器用一个状态行来回应，包括消息的协议版本和成功或错误代码，然后是一个包含服务器信息、实体元信息和可能的实体主体内容的类似 MIME 的消息。HTTP和MIME之间的关系在附录19.4中描述。

大多数 HTTP 通信是由用户代理发起的，包括对某个起源服务器上的资源的请求。在最简单的情况下，这可以通过用户代理（UA）和源服务器（O）之间的单一连接（v）来完成。

              request chain ------------------------>
           UA -------------------v------------------- O
              <----------------------- response chain

当请求/响应链中存在一个或多个中间人时，就会出现更复杂的情况。有三种常见的中介形式：代理、网关和隧道。代理是一个转发代理（agen），接收绝对形式的 URI 请求，重写全部或部分消息，并将重新格式化的请求转发给 URI 所确定的服务器。网关是一个接收代理（agen），作为其他一些服务器之上的一层，如果有必要，将请求翻译成底层服务器的协议。隧道作为两个连接之间的中继点，而不改变消息；当通信需要通过一个中间人（如防火墙）时，即使中间人不能理解消息的内容，也会使用隧道。

          request chain -------------------------------------->
       UA -----v----- A -----v----- B -----v----- C -----v----- O
          <------------------------------------- response chain

上图显示了用户代理和源服务器之间的三个中介（A、B 和 C）。一个穿越整个链条的请求或响应信息将通过四个独立的连接。这种区分很重要，因为一些 HTTP 通信选项可能只适用于与最近的、非隧道邻居的连接，只适用于链的端点，或适用于沿链的所有连接。虽然图表是线性的，但每个参与者都可能参与多个同时进行的通信。例如，B可能在处理 A 的请求的同时，还在接收 A 以外的许多客户的请求，和/或转发请求到 C 以外的服务器。

任何不作为隧道的通信方可以使用内部缓存来处理请求。缓存的作用是，如果链条上的一个参与者有一个适用于该请求的缓存响应，那么请求/响应链就会缩短。下面说明了如果 B 拥有 O（通过 C）对一个没有被 UA 或 A 缓存的请求的早期响应的缓存副本，那么产生的链。

          request chain ---------->
       UA -----v----- A -----v----- B - - - - - - C - - - - - - O
          <--------- response chain

并非所有的响应都是有用的可缓冲的，有些请求可能包含对缓冲行为有特殊要求的修饰语。第 13 节中定义了HTTP 对缓冲行为和可缓冲响应的要求。

事实上，目前在万维网上有各种各样的缓存和代理的结构和配置正在试验或部署。这些系统包括国家层次的代理缓存以节省跨洋带宽，广播或多播缓存条目的系统，通过 CD-ROM 分发缓存数据子集的组织，等等。HTTP 系统被用于高带宽链接的企业内部网，以及通过低功率无线电链接和间歇性连接的 PDA 访问。HTTP/1.1 的目标是支持已经部署的各种各样的配置，同时引入协议结构，以满足那些建立需要高可靠性的网络应用程序的人的需要，如果不能这样，至少要有可靠的故障指示。

HTTP 通信通常通过 TCP/IP 连接进行。默认的端口是 TCP 80 [19]，但也可以使用其他端口。这并不排除 HTTP 可以在互联网上或其他网络上的任何其他协议之上实现。HTTP 只假定有一个可靠的传输；任何提供这种保证的协议都可以使用；HTTP/1.1 请求和响应结构对有关协议的传输数据单元的映射超出了本规范的范围。

在 HTTP/1.0 中，大多数实现为每个请求/响应交换使用一个新的连接。在 HTTP/1.1 中，一个连接可以用于一个或多个请求/响应交换，尽管连接可能因为各种原因被关闭（见第 8.1 节）。