1. 引言 (Introduction)

1 引言

1.1 目的

超文本传输协议 (Hypertext Transfer Protocol, HTTP) 是一种应用层协议, 用于分布式, 协作式, 超媒体信息系统. 自 1990 年以来, HTTP 一直被 World-Wide Web 全球信息计划使用. HTTP 的第一个版本称为 HTTP/0.9, 是一种用于在 Internet 上传输原始数据的简单协议. RFC 1945 [6] 定义的 HTTP/1.0 改进了该协议, 允许消息采用类似 MIME 的消息格式, 包含有关被传输数据的元信息以及对请求/响应语义的修饰. 但是, HTTP/1.0 没有充分考虑分层 proxy, caching, 持久连接需求或 virtual host 的影响. 此外, 大量自称为 "HTTP/1.0" 但实现不完整的应用不断出现, 使得协议版本必须变化, 以便两个通信应用能够确定彼此的真实能力.

本规范定义称为 "HTTP/1.1" 的协议. 为确保其功能能够可靠实现, 该协议包含比 HTTP/1.0 更严格的要求.

实用的信息系统需要的不只是简单检索, 还包括搜索, 前端更新和注释等功能. HTTP 允许一个开放式的方法和头部集合, 用于指明请求目的 [47]. 它建立在统一资源标识符 (Uniform Resource Identifier, URI) [3] 提供的引用规则之上, 通过位置 (URL) [4] 或名称 (URN) [20] 指明方法要应用到的资源.

消息以类似 Internet mail [9] 的格式传递, 如 Multipurpose Internet Mail Extensions (MIME) [7] 所定义.

HTTP 也被用作用户代理与其他 Internet 系统的 proxy/gateway 之间通信的通用协议, 这些系统包括 SMTP [16], NNTP [13], FTP [18], Gopher [2] 和 WAIS [10] 协议所支持的系统. 通过这种方式, HTTP 允许对各种应用提供的资源进行基本超媒体访问.

1.2 要求

本文档中的关键字 "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 术语

本规范使用若干术语来指代 HTTP 通信的参与者角色以及通信对象.

connection 为通信目的在两个程序之间建立的传输层虚电路.

message HTTP 通信的基本单位, 由符合第 4 节所定义语法的结构化 octet 序列组成, 并通过 connection 传输.

request HTTP request message, 如第 5 节定义.

response HTTP response message, 如第 6 节定义.

resource 可由 URI 标识的网络数据对象或服务, 如第 3.2 节定义. 资源可以有多个 representation (例如多种语言, 数据格式, 大小和分辨率), 或以其他方式变化.

entity 作为 request 或 response 载荷传输的信息. entity 由 entity-header 字段形式的元信息和 entity-body 形式的内容组成, 如第 7 节所述.

representation 包含在 response 中并受 content negotiation 约束的 entity, 如第 12 节所述. 与某一特定 response status 关联的 representation 可以存在多个.

content negotiation 在处理 request 时选择适当 representation 的机制, 如第 12 节所述. 任一 response 中 entity 的 representation 都可以协商 (包括错误 response).

variant 在任何给定时刻, 一个 resource 可以有一个或多个与之关联的 representation. 这些 representation 中的每一个都称为 varriant'. 使用术语 variant' 并不必然意味着该 resource 受 content negotiation 约束.

client 为发送 request 而建立 connection 的程序.

user agent 发起 request 的 client. 这些通常是浏览器, 编辑器, spider (遍历 Web 的机器人) 或其他最终用户工具.

server 接受 connection 以通过返回 response 来服务 request 的应用程序. 任一给定程序都可能既能作为 client, 也能作为 server; 这里使用这些术语时, 只指该程序在特定 connection 中所扮演的角色, 而不是泛指该程序的能力. 同样, 任一 server 都可以充当 origin server, proxy, gateway 或 tunnel, 并根据每个 request 的性质切换行为.

origin server 给定 resource 所驻留或将被创建的 server.

proxy 一种中介程序, 同时充当 server 和 client, 代表其他 client 发出 request. request 可在内部处理, 或经可能的转换后转发给其他 server. proxy MUST 实现本规范的 client 和 server 要求. "transparent proxy" 是指除了 proxy authentication 和 identification 所要求的内容外, 不修改 request 或 response 的 proxy. "non-transparent proxy" 是指为了向 user agent 提供某种附加服务而修改 request 或 response 的 proxy, 例如组注释服务, media type 转换, 协议降级或匿名过滤. 除非明确说明 transparent 或 non-transparent 行为, HTTP proxy 要求适用于这两类 proxy.

gateway 为其他某个 server 充当中介的 server. 与 proxy 不同, gateway 接收 request 时就像它是所请求 resource 的 origin server; 发出 request 的 client 可能不知道自己正在与 gateway 通信.

tunnel 在两个 connection 之间充当盲中继的中介程序. 一旦激活, tunnel 就不被视为 HTTP 通信的一方, 尽管该 tunnel 可能由 HTTP request 发起. 当被中继的两个 connection 的两端都关闭时, tunnel 即不复存在.

cache 程序的 response message 本地存储, 以及控制其消息存储, 检索和删除的子系统. cache 存储可缓存的 response, 以便在后续等价 request 中减少响应时间和网络带宽消耗. 任何 client 或 server 都可以包含 cache, 但充当 tunnel 的 server 不能使用 cache.

cacheable 如果允许 cache 存储某个 response message 的副本以用于回答后续 request, 则该 response 是 cacheable. HTTP response cacheability 的判定规则在第 13 节定义. 即使某个 resource 是 cacheable, 对于特定 request, cache 是否可以使用其缓存副本仍可能受到额外约束.

first-hand 如果 response 直接且无不必要延迟地来自 origin server, 可能经由一个或多个 proxy, 则它是 first-hand. 如果 response 的有效性刚刚直接由 origin server 检查过, 它也是 first-hand.

explicit expiration time origin server 期望 entity 不再由 cache 在未经进一步验证的情况下返回的时间.

heuristic expiration time 当没有 explicit expiration time 可用时, cache 指派的 expiration time.

age response 的 age 是自它由 origin server 发送或成功验证以来经过的时间.

freshness lifetime response 生成时间与其 expiration time 之间的时间长度.

fresh 如果 response 的 age 尚未超过其 freshness lifetime, 则该 response 是 fresh.

stale 如果 response 的 age 已超过其 freshness lifetime, 则该 response 是 stale.

semantically transparent 对特定 response 而言, 当 cache 的使用除了提升性能外, 既不影响发出 request 的 client, 也不影响 origin server 时, 该 cache 以 "semantically transparent" 方式运行. 当 cache 语义透明时, client 收到的 response 与其 request 由 origin server 直接处理时本会收到的 response 完全相同 (hop-by-hop header 除外).

validator 用于判断 cache entry 是否为某个 entity 的等价副本的协议元素 (例如 entity tag 或 Last-Modified time).

upstream/downstream Upstream 和 downstream 描述 message 的流向: 所有 message 都从 upstream 流向 downstream.

inbound/outbound Inbound 和 outbound 指 message 的 request 路径和 response 路径: "inbound" 表示 "朝 origin server 方向传播", "outbound" 表示 "朝 user agent 方向传播".

1.4 总体操作

HTTP 协议是一种 request/response 协议. client 以 request method, URI 和 protocol version 的形式向 server 发送 request, 随后在与 server 的 connection 上发送一个类似 MIME 的 message, 其中包含 request modifier, client 信息以及可能的 body 内容. server 以 status line 响应, 其中包括 message 的 protocol version 和成功或错误代码, 随后是一个类似 MIME 的 message, 其中包含 server 信息, entity 元信息以及可能的 entity-body 内容. HTTP 与 MIME 的关系见附录 19.4.

大多数 HTTP 通信由 user agent 发起, 由一个应用到某个 origin server 上 resource 的 request 组成. 在最简单的情况下, 这可以通过 user agent (UA) 与 origin server (O) 之间的单个 connection (v) 完成.

     request chain ------------------------&gt;
  UA -------------------v------------------- O
     &lt;----------------------- response chain

当 request/response 链中存在一个或多个 intermediary 时, 情况会更复杂. 中介有三种常见形式: proxy, gateway 和 tunnel. proxy 是转发代理, 接收绝对形式 URI 的 request, 重写全部或部分 message, 并将重新格式化后的 request 转发给 URI 标识的 server. gateway 是接收代理, 作为某些其他 server 之上的一层运行, 必要时将 request 转换为底层 server 的协议. tunnel 在两个 connection 之间充当中继点而不改变 message; 当通信需要穿过中介 (如 firewall), 即使该中介无法理解 message 内容时, 会使用 tunnel.

       request chain -------------------------------------->
    UA -----v----- A -----v----- B -----v----- C -----v----- O
       &lt;------------------------------------- response chain

上图显示 user agent 与 origin server 之间有三个 intermediary (A, B 和 C). 传播完整链路的 request 或 response message 会经过四个独立 connection. 这种区别很重要, 因为某些 HTTP 通信选项可能只适用于最近的非 tunnel 邻居 connection, 只适用于链的端点, 或适用于链上的所有 connection.

虽然图是线性的, 每个参与者都可能同时参与多个通信. 例如, B 在处理 A 的 request 的同时, 可能正在接收许多 A 以外 client 的 request, 和/或向 C 以外的 server 转发 request.

任何不充当 tunnel 的通信方都可以使用内部 cache 来处理 request. cache 的效果是: 如果链上的某个参与者拥有适用于该 request 的已缓存 response, request/response 链就会缩短. 下面示意了当 B 拥有 O 先前 response (经由 C) 的缓存副本, 且该 request 未被 UA 或 A 缓存时形成的链.

       request chain ---------->
    UA -----v----- A -----v----- B - - - - - - C - - - - - - O
       &lt;--------- response chain

并非所有 response 都适合缓存, 某些 request 也可能包含对 cache 行为提出特殊要求的 modifier. HTTP 对 cache 行为和 cacheable response 的要求在第 13 节定义.

实际上, 当前正在 World Wide Web 上试验或部署多种 cache 和 proxy 架构与配置. 这些系统包括用于节省跨洋带宽的全国性 proxy cache 层级, 广播或组播 cache entry 的系统, 通过 CD-ROM 分发缓存数据子集的组织, 等等. HTTP 系统既用于高带宽链路上的企业 intranet, 也用于通过低功耗无线链路和间歇性连接访问的 PDA. HTTP/1.1 的目标是支持已经部署的各种配置, 同时引入协议构造, 满足构建要求高可靠性的 Web 应用者的需求; 如果无法满足, 至少也要提供可靠的失败指示.

HTTP 通信通常通过 TCP/IP connection 进行. 默认端口为 TCP 80 [19], 但也可以使用其他端口. 这并不排除在 Internet 上的任何其他协议之上或在其他网络上实现 HTTP. HTTP 只假定可靠传输; 任何提供此类保证的协议都可以使用. HTTP/1.1 request 和 response 结构到相关协议传输数据单元的映射超出本规范范围.

在 HTTP/1.0 中, 大多数实现为每次 request/response 交换使用一个新 connection. 在 HTTP/1.1 中, 一个 connection 可以用于一次或多次 request/response 交换, 但 connection 可能因多种原因关闭 (见第 8.1 节).