超文本传输协议-HTTP/1.1（修订版）
说明
本文档规定了互联网社区的标准组协议，并需要讨论和建议以便更加完善。请参考 “互联网官方协议标准”（STD 1）来了解本协议的标准化状态。本协议不限流传发布。
版权声明
Copyright （C） The Internet Society （1999）. All Rights Reserபைடு நூலகம்ed.
内容协商（content negotiation） 任 当服务一个请求时选择资源的一种适当的表示形式的机制（mechanism），如第 12 节所述。 何响应里实体的表现形式都是可协商的（包括错误响应）。 变量（variant） 在 某 个时 刻 ，一个资源对应的表现形式（ representation ）可以有一个或多个（译注：一个 URI 请求一个资源，但返回的是此资源对应的表现形式，这根据内容协商决定）。每个表现形 式 （ representation ） 被 称 作 一 个 变 量 。 ‘ 变 量 ’ 这 个 术 语 的 使 用 并 不 意 味 着 资 源 （resource）是由内容协商决定的.。 客户端（client） 为发送请求建立连接的程序.。 用户代理（user agent） 初始化请求的客户端程序。常见的如浏览器，编辑器，蜘蛛（可网络穿越的机器人），或其他 的终端用户工具. 服务器（Server） 服务器是这样一个应用程序，它同意请求端的连接，并发送响应（ response）。任何给定的程 序都有可能既做客户端又做服务器；我们使用这些术语是为了说明特定连接中应用程序所担当 的角色，而不是指通常意义上应用程序的能力。同样，任何服务器都可以基于每个请求的性质 扮演源服务器，代理，网关，或者隧道等角色之一。 源服务器（Origin server） 存在资源或者资源在其上被创建的服务器（server）被成为源服务器（origin server）。 代理（ Proxy） 代理是一个中间程序，它既可以担当客户端的角色也可以担当服务器的角色。代理代表客户端 向服务器发送请求。客户端的请求经过代理，会在代理内部得到服务或者经过一定的转换转至 其 他 服务器。一个代理必 须 能同时实现本规范 中 对 客 户端和服务器 所 作的要求。 透 明代理 （ transparent proxy ）需要代理 认证 和代理识 别 ， 而 不修 改 请求或响应。 非透 明代理（ nontransparent proxy）需修改请求或响应，以便为用户代理（ user agent）提供附加服务，附加 服务包括组注释服务，媒体类型转换，协议简化，或者匿名过滤等。除非透明行为或非透明行 为经被显式地声明，否则，HTTP 代理既是透明代理也是非透明代理。 网关（gateway） 网关其实是一个服务器，扮演着代表其它服务器为客户端提供服务的中间者。 与代理（proxy） 不同，网关接收请求，仿佛它就是请求资源的源服务器。请求的客户端可能觉察不到它正在同 网关通信。 隧道（tunnel） 隧道也是一个中间程序，它一个在两个连接之间充当盲目中继（blind relay）的中间程序。 一旦 隧道处于活动状态，它不能被认为是这次 HTTP 通信的参与者，虽然 HTTP 请求可能已经把它 初始化了。当两端的中继连接都关闭的时候，隧道不再存在。 缓存（cache） 缓存是程序响应消息的本地存储。 缓存是一个子系统，控制消息的存储、 获取和删除。 缓存里存 放可缓存的响应（ cacheable response）为的是减少对将来同样请求的响应时间和网络带宽消 耗。 任一客户端或服务器都可能含有缓存，但缓存不能存在于一个充当隧道（tunnel）的服务器 里。
1.3 术语
本说明用到了若干术语，以表示 HTTP 通信中各参与者和对象扮演的不同角色。 连接（connection） 为通信而在两个程序间建立的传输层虚拟电路。 消息（message） HTTP 通信中的基本单元。它由一个结构化的八比特字节序列组成，与第 4 章定义的句法相匹 配，并通过连接得到传送。 请求（request） 一种 HTTP 请求消息，参看第 5 章的定义。 响应（response） 一种 HTTP 响应消息，参看第 6 章的定义。 资源（resource） 一种网络数据对象或服务，可以用第 3.2 节定义的 URI 指定。资源可以以多种表现方式（例如 多种语言，数据格式，大小和分辨率）或者根据其它方面而而不同的表现形式。 实体（entity） 实体是请求或响应的有效承载信息。一个实体包含元信息和内容，元信息以实体头域（ entityheader field）形式表示，内容以消息主体（entity-body）形式表示。在第 7 章详述。 表现形式 （representation） 一个响应包含的实体是由内容协商（content negotiation）决定的。 如第 12 章所述。 有可能存在 一个特定的响应状态码对应多个表现形式。
摘要
超文本传输协议（HTTP）是一种为分布式，协作式的，超媒体信息系统。 它是一种通用的，无 状态（stateless）的协议，除了应用于超文本传输外，它也可以应用于诸如名称服务器和分布 对象管理系统之类的系统，这可以通过扩展它的请求方法，错误代码和消息头 [47] 来实现 。 HTTP 的一个特性就是是数据表现形式是可以定义的和可协商性的，这就允许系统能独立于于 数据传输被构建。 HTTP 在 1990 年 WWW 全 球 信 息 刚 刚 起 步 的 时 候 就 得 到 了 应 用 。 本 说 明 书 详 细 阐 述 了 HTTP/1.1 协议，是 RFC 2068 的修订版[33]。
实际的信息系统除了简单的获取信息之外，还要求更多的功能，包括查找（ search），终端更 新（ front-end update ）和注解（ annotation ）。 HTTP 为请求提供可扩充方法集和消息头集 [47]。HTTP 是建立在统一资源标识符（URI）[3]的约束上的，作为一个地址（URL）[4]或名称 （URN）[20]，以指定被一个方法使用的资源。消息以一种类似于互联网邮件 [9]消息格式来传 输的，互联网消息格式定义于多目的互联网邮件扩展（MIME）[7]里。 HTTP 也是用于用户代理（ user agents）和其它互联网系统的代理 /网关之间通信的通信协议， 这些互联网系统可能由 SMTP[16],NNTP[13],FTP[18]，Gopher[2]和 WAIS[10]协议支持。通过 这种方式，HTTP 允许不同的应用程序对资源进行基本的超媒体访问。
目录（略）
1 引论
1.1 目的
超文本传输协议（HTTP）是一种为分布式的，协作的，超媒体信息系统，它是面向应用层的 协议。 在 1990 年 WWW 全球信息刚刚起步的时候 HTTP 就得到了应用。 HTTP 的第一个版本叫做 HTTP/0.9,是一种为互联网原始数据传输服务的简单协议。由 RFC 1945[6]定义的 HTTP/1.0 进一 步完善了这个协议。它允许消息以类 MIME 消息的格式传送，它包括传输数据的元信息和对请 求/响应语义的修饰。 但是，HTTP/1.0 没有充分考虑到分层代理，缓存的，以及持久连接和虚拟 主机的需求的影响。并且随着不完善的 HTTP/1.0 应用程序的激增，这就迫切需要一个新的版本， 以便能使两个通信程序能够确定彼此的真实能力。 此规范定义的协议叫做“HTTP/1.1”，.这个协议与 HTTP/1.0 相比，此规范更为严格，以确保 各个协议的特征得到可靠实现。
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）。