《Hypertext Transfer Protocol -- HTTP/1.0》翻译

一、介绍

1、目的

超文本传输协议 （HTTP） 是一种应用程序级协议，具有分布式、协作、超媒体信息系统所需的轻量级和速度。自1990年以来，HTTP一直由万维网全球信息倡议使用。此规范反映了也称为"HTTP/1.0"的协议的常见用法。此规范描述了在大多数 HTTP/1.0 客户端和服务器中似乎一致实现的功能。规范分为两个部分。本文档的正文中描述了实现通常一致的 HTTP 功能。附录 D 中列出了那些实现很少或不一致的功能。

实用的信息系统需要比简单检索更多的功能，包括搜索、前端更新和注释。HTTP 允许使用一组开放式方法来指示请求的用途。它建立在统一资源标识符 （URI）提供的引用规则的基础上，作为位置 （URL）或名称 （URN），用于指示要应用方法的资源。消息的传递格式类似于互联网邮件和多用途互联网邮件扩展 （MIME）使用的格式。

HTTP还用作用户代理与其他互联网协议（如SMTP，NNTP，FTP，Gopher和WAIS）之间的通信的通用协议，允许基本的超媒体访问从各种应用程序可用的资源并简化用户代理的实现。

2、术语

该规范使用了许多术语来指代HTTP通信中的参与者和对象所扮演的角色。

术语	解释
connection	一种传输层虚拟电路，用于两个应用程序之间的通信。
message	HTTP通信的基本单元，由符合第4节中定义的语法的结构化的字节序列组成，并通过connection传输。
request	HTTP 请求消息（如第 5 节中所定义）。
response	HTTP 响应消息（如第 6 节中所定义）。
resource	可由 URI 标识的网络数据对象或服务（第 3.2 节）。
entity	数据资源的特定表示形式或再现，或来自服务资源的答复，可以包含在请求或响应消息中。 实体由实体标头形式的元信息和实体主体形式的内容组成。
client	一个应用程序，用于建立用于发送请求的连接。
user agent	发起请求的客户端。这些工具通常是浏览器、编辑器、爬行器(web遍历机器人)或其他终端用户工具。
server	一个应用程序，它接受连接，以便通过发回响应来为请求提供服务。
origin server	给定资源所在的服务器或要创建的服务器。
proxy	一种中间程序，它同时充当服务器和客户端，以便代表其他客户端发出请求。 请求在内部进行处理，或者通过将它们传递（可能进行转换）传递到其他服务器来处理。 代理必须在转发请求消息之前对其进行解释，并在必要时重写该消息。 roxies 通常用作通过网络防火墙的客户端门户，并用作帮助器应用程序，用于通过用户代理未实现的协议处理请求。
gateway	充当其他服务器的中介的服务器。 与代理不同，网关接收请求，就好像它是所请求资源的源服务器一样。 请求客户端可能不知道它正在与网关通信。 网关通常用作通过网络防火墙的服务器端门户，并用作访问存储在非 HTTP 系统上的资源的协议转换器。
tunnel	隧道是一种中间程序，充当两个连接之间的盲中继。 一旦激活，隧道将不被视为 HTTP 通信的一方，尽管该隧道可能已由 HTTP 请求启动。 当中继连接的两端关闭时，隧道将不复存在。 当需要门户并且中介不能或不应该解释中继通信时，将使用隧道。
cache	程序的响应消息的本地存储以及控制其消息存储、检索和删除的子系统。 缓存存储可缓存的响应，以减少将来等效请求的响应时间和网络带宽消耗。 任何客户端或服务器都可能包含缓存，但服务器在充当隧道时不能使用缓存。

任何给定的程序都可以既是客户端又是服务器；我们对这些术语的使用仅指程序对特定连接执行的角色，而不是程序的一般功能。同样，任何服务器都可以充当源服务器、代理、网关或隧道，根据每个请求的性质切换行为。

3、概述

HTTP 协议基于请求/响应范例。客户端与服务器建立连接，并以请求方法、URI 和协议版本的形式向服务器发送请求，后跟包含请求修饰符、客户端信息和可能的正文内容的类似 MIME 的消息。服务器使用状态行进行响应，包括邮件的协议版本和成功或错误代码，后跟包含服务器信息、实体信息以及可能的正文内容的类似 MIME 的邮件。
大多数HTTP通信是由用户代理发起的，由应用于某个源服务器上的资源的请求组成。在最简单的情况下，这可以通过用户代理(UA)和源服务器(O)之间的单个连接(v)来完成。

当一个或多个中介体出现在请求响应链中时，会出现更复杂的情况。有三种常见的中介形式：代理、网关和隧道。代理是一个转发代理，以绝对形式接收对 URI 的请求，重写全部或部分消息，并将重新格式化的请求转发到由 URI 标识的服务器。网关是一个接收代理，充当某些其他服务器之上的层，并在必要时将请求转换为基础服务器的协议。隧道充当两个连接之间的中继点，而不更改消息；当通信需要通过中介（如防火墙）时，即使中介无法理解消息的内容，也会使用隧道。

上图显示了用户代理和源服务器之间的三个中介体(A、B和C)。在整个链中传播的请求或响应消息必须通过四个单独的连接。这个区别很重要，因为一些HTTP通信选项可能只适用于与最近的、非隧道邻居的连接，只适用于链的端点，或者适用于链上的所有连接。虽然这个图是线性的，但是每个参与者可以同时进行多次交流。例如，在处理A请求的同时，B可能正在接收来自A以外的许多客户机的请求，并且或将请求转发给C以外的服务器。通信的任何一方，如果不是作为一个隧道，可以使用一个内部缓存来处理请求。缓存的效果是，如果链上的一个参与者有一个缓存的响应适用于该请求，那么请求/响应链就会缩短。下面说明了如果 B 具有来自 O 的早期响应（通过 C）的缓存副本，则生成的链适用于尚未被 UA 或 A 缓存的请求。

并非所有响应都是可缓存的，并且某些请求可能包含对缓存行为提出特殊要求的修饰符。一些HTTP1.0应用程序使用启发式方法来描述哪些是可缓存响应，哪些不是，但这些规则并不是标准化的。在互联网上，HTTP通信通常通过TCP/IP连接进行。默认端口为TCP 80[15]，其他端口也可以使用。这并不妨碍HTTP在互联网或其他网络上的任何其他协议之上实现。HTTP只假定可靠的传输；可以使用任何提供此类保证的协议，并且 HTTP/1.0 请求和响应结构到相关协议的传输数据单元的映射不在本规范的范围之内。

除了实验应用程序，目前的实践要求客户端在每个请求之前建立连接，服务器在发送响应后关闭连接。客户端和服务器都应该意识到，由于用户操作、自动超时或程序失败，任何一方都可能过早地关闭连接，并且应该以一种可预测的方式处理这种关闭。在任何情况下，任何一方或双方关闭连接始终会终止当前请求，无论其状态如何。

4、HTTP 和 MIME

HTTP1.0使用了许多为MIME定义的结构，如RFC 1521[5]中定义的那样。附录 C 描述了 HTTP 上下文允许使用与互联网邮件中通常不同的互联网媒体类型的方式，并给出了这些差异的基本原理。

二、符号约定和通用语法

1、补充反馈方式

本文档中指定的所有机制都以散文体和类似于RFC 822[7]所使用的扩展Backus-Naur Form (BNF)的形式进行了描述。实现者需要熟悉符号才能理解这个规范。增强的 BNF 包括以下构造：

1、name = definition

规则的名称只是名称本身（没有任何封闭的"<“和”>"），并且由相等字符"="与其定义分开。空格之所以重要，是因为延续行的缩进用于指示跨越多行的规则定义。某些基本规则是大写的，例如SP，LWS，HT，CRLF，DIGIT，ALPHA等。在定义中使用尖括号，只要它们的存在有助于辨别规则名称的使用。

2、“literal”

引号将文字文本引起来。除非另有说明，否则文本不区分大小写。

3、rule1 | rule2

条形分隔的元素（“I”）是替代项，例如，“yes | no” 将接受是或否。

4、(rule1 rule2)

用圆括号括起来的元素被视为单个元素。因此，"（elem （foo |bar） elem）“允许令牌序列"elem foo elem"和"elem bar elem”。

5、*rule

元素前面的字符"*“表示重复。完整形式是”<n> *<m>element"，表示至少<n>和最多<m>出现元素。。默认值为 0 且无穷大，因此"*（element）"允许任何数字，包括零；"1 *元素"至少需要一个;和"1 * 2element"允许一个或两个。

6、[rule]

方括号包含可选元素；"[foo bar]“相当于”*1（foo bar）"。

7、N rule

具体重复："<n>(element)“等同于”<n>*<n>(element)"；也就是说，正好有n个(元素)出现。因此，2DIGIT 是一个 2 位数字，而 3ALPHA 是一个由三个字母字符组成的字符串。

8、#rule

定义了类似于"*“的构造”#"，用于定义元素列表。完整的形式是“<n>#<m>element”，表示至少n个元素，最多m个元素，每个元素由一个或多个逗号(，)和可选线性空格(LWS)分隔。这使得通常的列表形式非常容易；诸如"（ *LWS element *（ *LWS “，” *LWS element ））“之类的规则可以显示为"1#element”。无论在何处使用此构造，都允许空元素，但不会影响存在的元素计数。也就是说，"(element), , (element)“是允许的，但只能算作两个元素。因此，如果至少需要一个元素，则必须至少存在一个非空元素。默认值为 0 且无穷大，因此”#(element)"允许任何数字，包括零；"1#元素"至少需要一个;和"1#2element"允许一个或两个。

9、; comment

分号在规则文本的右侧设置了一段距离，开始了一直到行尾的注释。这是一种与规范并行包含有用注释的简单方法。

10、implied *LWS

此规范描述的语法是基于单词的。除非另有说明，否则线性空格 （LWS） 可以包含在任意两个相邻单词（标记或带引号的字符串）之间，以及相邻标记和分隔符（tspecials）之间，而无需更改字段的解释。任何两个标记之间必须至少存在一个分隔符（tspecials），否则它们将被解释为单个标记。但是，应用程序在生成HTTP构造时应尝试遵循"通用形式"，因为存在一些无法接受通用形式以外的任何内容的实现。

2、基本规则

本规范始终使用以下规则来描述基本分析构造。US-ASCII 编码字符集由 [17] 定义。


HTTP/1.0 将八位字节序列 CR LF 定义为除实体主体之外的所有协议元素的行尾标记（有关容错性应用程序，请参见附录 B）。实体正文中的行尾标记由其关联的媒体类型定义，如第 3.6 节所述。

如果每个延续行都以空格或水平制表符开头，则可以将 HTTP/1.0 标头折叠到多行上。所有线性空格（包括折叠）都具有与 SP 相同的语义。

然而，一些应用程序不希望折叠标题行，HTTP1.0应用程序也不应该生成折叠标题行。

TEXT 规则仅用于描述性字段内容和不应由消息分析器解释的值。*TEXT 的单词可能包含来自 US-ASCII 以外的字符集的八位字节。

包含 USASCII 字符集之外的八位字节的标题字段 TEXT 的收件人可能会假定它们表示 ISO-8859-1 字符。

十六进制数字字符用于多个协议元素中。

许多 HTTP/1.0 标头字段值由 LWS 或特殊字符分隔的单词组成。这些特殊字符必须位于带引号的字符串中，才能在参数值中使用。


在一些HTTP报头字段中，可以通过用圆括号包围注释文本来包含注释。只有在包含"注释"作为其字段值定义的一部分的字段中才允许注释。在所有其他字段中，括号被视为字段值的一部分。

如果文本字符串使用双引号引起来，则该字符串将解析为单个单词。

在 HTTP/1.0 中不允许使用反斜杠 （" \ "） 字符的单字符引用。

三、协议参数

1、HTTP版本

HTTP 使用"<major>.<minor>"编号方案来指示协议的版本。协议版本控制策略的目的是允许发送方指明消息的格式及其理解进一步HTTP通信的能力，而不是通过该通信获得的特性。对于添加不影响通信行为或仅添加到可扩展字段值的消息组件，不会对版本号进行任何更改。当对协议所做的更改增加的特性不会改变一般的消息解析算法，但可能会增加消息语义并暗示发送方的额外功能时，<minor>会增加。当协议内的消息格式改变时，<major>会增加。

HTTP 消息的版本由消息第一行中的 HTTP 版本字段指示。如果未指定协议版本，则接收方必须假定邮件采用简单的 HTTP/0.9 格式。

HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT

请注意，主版本号和次版本号应该被视为单独的整数，并且每个数字的增量都可能大于单个数字。因此，HTTP/2.4 的版本低于 HTTP/2.13，而 HTTP/2.13 又低于 HTTP/12.3。前导零应该被接收方忽略，发送方永远不会生成它。

本文档定义了 HTTP 协议的 0.9 和 1.0 版本。发送完整请求或完整响应消息（由此规范定义）的应用程序必须包含 HTTP 版本"HTTP/1.0"。

HTTP/1.0 服务器必须：

• 识别 HTTP/0.9 和 HTTP/1.0 请求的请求行的格式；

• 理解HTTP/0.9或HTTP/1.0格式的任何有效请求；

• 客户端使用的相同协议版本的消息进行适当的响应。

HTTP/1.0 客户端必须：

• 识别 HTTP/1.0 响应的状态行格式；
• 理解 HTTP/0.9 或 HTTP/1.0 格式的任何有效响应.

代理和网关应用程序在转发以不同于应用程序原生HTTP版本的格式接收的请求时必须小心。由于协议版本指示发送方的协议功能，因此代理/网关绝不能发送版本指示符大于其本机版本的消息；如果收到更高版本的请求，代理/网关必须降级请求版本或响应错误。版本低于应用程序原生格式的请求可以在转发前进行升级；代理/网关对该请求的响应必须遵循上面列出的服务器要求。

2、统一资源标识符

URI有许多名称：WWW地址，通用文档标识符，通用资源标识符，最后是统一资源定位器（URL）和名称（URN）的组合。就HTTP而言，统一资源标识符只是格式化的字符串，通过名称，位置或任何其他特征来识别网络资源。

1、通用语法

HTTP 中的 URI 可以以绝对形式表示，也可以相对于某些已知的基本 URI 表示，具体取决于它们的使用上下文。这两种形式的区别在于，绝对 URI 始终以方案名称开头，后跟冒号。

有关 URL 语法和语义的明确信息，请参阅 RFC 1738 和 RFC 1808 。上面的 BNF 包括 RFC 1738 指定的有效 URL 中不允许使用的国内字符，因为 HTTP 服务器不受限制于允许表示地址 rel_path 部分的未保留字符集，并且 HTTP 代理可能会收到对 RFC 1738 未定义的 URI 的请求。

2、http URL

“http"方案用于通过 HTTP 协议查找网络资源。本节定义 http_URL 的特定于方案的语法和语义。

如果端口为空或未给出，则假定端口为 80。语义是，被标识的资源位于服务器上，在该主机的那个端口上侦听 TCP 连接，并且该资源的Request-URI 是 abs 路径。如果 URL 中不存在 abs_path，则在用作请求 URI 时，必须将其指定为”/"（第 5.1.2 节）。

注：虽然HTTP协议独立于传输层协议，但HTTP_URL仅根据其 TCP 位置标识资源，因此非 TCP 资源必须由其他URI方案标识。

"http"URL 的规范形式是通过将主机中的任何 UPALPHA 字符转换为其 LOALPHA 等效字符（主机名不区分大小写），如果端口为 80，则省略 [ “：” port ]，并将空abs_path替换为 "/"来获得。

3、日期/时间格式

HTTP/1.0 应用程序历来允许使用三种不同的格式来表示日期/时间戳：

第一种格式是首选的互联网标准，它代表了RFC 1123（RFC 822的更新）定义的固定长度子集。第二种格式是常用的，但基于过时的 RFC 850 日期格式，并且缺少四位数的年份。解析日期值的 HTTP/1.0 客户端和服务器应接受所有三种格式，但绝不能生成第三种 （asctime） 格式。

注：鼓励日期值的接收者能够可靠地接受可能由非 HTTP 应用程序生成的日期值，有时通过代理/网关检索或将邮件发布到 SMTP 或 NNTP 时就是这种情况。

所有 HTTP/1.0 日期/时间戳都必须以世界时间 （UT） 表示，也称为格林威治标准时间 （GMT），无一例外。这在前两种格式中通过将GMT作为时区的三个字母缩写表示出来，在阅读asctime格式时应该这样做。

注：日期/时间戳格式的 HTTP 要求仅适用于它们在协议流中的使用。客户端和服务器不需要将这些格式用于用户演示、请求记录等。

4、字符集

HTTP 使用的术语"字符集"的定义与 MIME 的定义相同：

• 术语"字符集"在本文档中用于指代一种用于一个或多个表的方法，用于将八位字节序列转换为字符序列。请注意，不需要在另一个方向上进行无条件转换，因为并非所有字符都可以在给定字符集中使用，并且字符集可以提供多个八位字节序列来表示特定字符。此定义旨在允许各种字符编码，从简单的单表映射（如 US-ASCII）到复杂的表切换方法（如使用 ISO 2022 技术的方法）。但是，与 MIME 字符集名称关联的定义必须完全指定要从八位字节到字符执行的映射。特别是，不允许使用外部分析信息来确定确切的映射。

注：术语"字符集"的这种用法通常称为"字符编码"。但是，由于 HTTP 和 MIME 共享同一注册表，因此共享术语也很重要。

HTTP 字符集由不区分大小写的标记标识。完整的令牌集由 IANA 字符集注册表定义。但是，由于该注册表没有为每个字符集定义单个一致的标记，因此我们在这里定义了最有可能与 HTTP 实体一起使用的字符集的首选名称。这些字符集包括由 RFC 1521 （US-ASCII 和 ISO-8859 字符集）注册的字符集，以及特别推荐在 MIME 字符集参数中使用的其他名称。

尽管 HTTP 允许将任意令牌用作字符集值，但在 IANA 字符集注册表中具有预定义值的任何令牌都必须表示该注册表定义的字符集。应用程序应将其字符集的使用限制为由 IANA 注册管理机构定义的字符集。

体主体的字符集应该被标记为该主体中使用的字符代码的最小公分母，但除了US-ASCII或ISO-8859-1标签之外，没有任何标签是首选的。

5、内容编码

内容编码值用于指示已应用于资源的编码转换。内容编码主要用于允许文档进行压缩或加密，而不会丢失其基础媒体类型的标识。通常，资源存储在此编码中，并且仅在呈现或类似用法之前进行解码。

注：为了将来的兼容性，HTTP/1.0 应用程序应将"gzip"和"compress"分别视为等同于"x-gzip"和"x-compress"。

所有内容编码值都不区分大小写。HTTP/1.0 在内容编码（第 10.3 节）标头字段中使用内容编码值。尽管该值描述了内容编码，但更重要的是它指示了删除编码所需的解码机制。请注意，单个程序可能能够解码多种内容编码格式。此规范定义了两个值：

1、x-gzip

由Jean-loup Gailly开发的文件压缩程序"gzip"（GNU zip）产生的编码格式。这种格式通常是带有32位CRC的Lempel-Ziv编码（LZ77）。

2、x-compress

由文件压缩程序"compress"产生的编码格式。这种格式是自适应的Lempel-Ziv-Welch编码（LZW）。

注：使用程序名称来标识编码格式是不可取的，对于将来的编码，应不鼓励使用。它们在这里的使用代表了历史实践，而不是好的设计。

6、媒体类型

HTTP 在 Content-Type 标头字段（第 10.5 节）中使用 Internet Media Types，以提供开放和可扩展的数据类型。

参数可以以属性/值对的形式跟随类型/子类型。

类型、子类型和参数属性名称不区分大小写。参数值可能区分大小写，也可能不区分大小写，具体取决于参数名称的语义。不得在类型和子类型之间生成 LWS，也不能在属性与其值之间生成 LWS。在收到具有无法识别参数的媒体类型后，用户代理应将该媒体类型视为无法识别的参数及其值不存在。

某些较旧的 HTTP 应用程序无法识别媒体类型参数。HTTP/1.0 应用程序应仅在定义消息内容所必需的情况下才使用媒体类型参数。

媒体类型值在互联网号码分配机构 （IANA） 注册。RFC 1590 中概述了媒体类型注册过程。不鼓励使用未注册的媒体类型。

1、规范化和文本默认值

互联网媒体类型以规范形式注册。通常，通过 HTTP 传输的实体正文在传输之前必须以适当的规范形式表示。如果正文已使用内容编码进行编码，则基础数据在编码之前应采用规范形式。

文本类型的媒体子类型在采用规范形式时使用 CRLF 作为文本换行符。但是，HTTP 允许传输文本媒体，当在实体正文中一致使用时，纯 CR 或 LF 单独表示换行符。单独 CR 和单独 LF 作为通过 HTTP 接收的文本媒体中的换行符的代表。此外，如果文本媒体以不分别使用 CR 和 LF 的八位字节 13 和 10 的字符集表示，就像某些多字节字符集的情况一样，则 HTTP 允许使用由该字符集定义的任何八位字节序列来表示等效的 CR 和 LF 作为换行符。这种关于换行符的灵活性仅适用于实体正文中的文本媒体；在任何 HTTP 控制结构（如标头字段和多部分边界）中，都不应用单独 CR 或 LF 代替 CRLF。

"charset"参数与某些媒体类型一起使用，以定义数据的字符集（第 3.4 节）。当发送方未提供显式字符集参数时，“文本"类型的媒体子类型被定义为在通过 HTTP 接收时具有默认字符集值"ISO-8859-1”。"ISO-8859-1"或其子集以外的字符集数据必须使用适当的字符集值进行标记，以便接收方能够一致地解释数据。

注：许多当前的HTTP服务器使用"ISO-8859-1"以外的字符集提供数据，而没有适当的标签。这种情况会降低互操作性，因此不建议这样做。为了弥补这一点，某些 HTTP 用户代理提供了一个配置选项，以允许用户在未给出字符集参数时更改媒体类型字符集的默认解释。

2、多部件类型

MIME 提供了许多"多部分"类型 – 在单个邮件的实体正文中封装多个实体。IANA 注册的多部分类型对 HTTP/1.0 没有任何特殊含义，但用户代理可能需要了解每种类型，以便正确解释每个正文部分的用途。HTTP 用户代理应遵循与 MIME 用户代理在收到多部分类型时执行的相同或类似的行为。HTTP 服务器不应假定所有 HTTP 客户端都已准备好处理多部分类型。

所有多部分类型共享一个通用语法，并且必须包含一个边界参数作为媒体类型值的一部分。消息正文本身就是一个协议元素，因此必须仅使用 CRLF 来表示正文部分之间的换行符。多部分正文部分可能包含对该部分的含义具有重要意义的 HTTP 标头字段。

7、产品标记

产品令牌用于允许通信应用程序通过简单的产品令牌（带有可选的斜杠和版本指示符）来标识自己。大多数使用产品令牌的字段还允许列出构成应用程序重要部分的子产品，并用空格分隔。按照惯例，产品按其重要性顺序列出，以识别应用。

举例：

产品令牌应该简短明了——明确禁止将其用于广告或其他非必要信息。尽管任何标记字符都可能出现在产品版本中，但此标记应仅用于版本标识符（即，同一产品的后续版本应仅在产品值的产品版本部分有所不同）。

四、HTTP 消息

1、消息类型

HTTP 消息由从客户端到服务器的请求以及从服务器到客户端的响应组成。

完整请求和完全响应使用 RFC 822 的通用消息格式来传输实体。这两条消息都可能包含可选的标头字段（也称为"标头"）和实体正文。实体正文与标头之间用空行（即，CRLF 前面没有任何内容的行）分隔。

简单请求和简单响应不允许使用任何标头信息，并且仅限于单个请求方法 （GET）。

不建议使用简单请求格式，因为它会阻止服务器识别返回实体的媒体类型。

2、消息头

HTTP报头字段，包括通用报头(第4.3章节)，请求报头(第5.2章节)，响应报头(第6.2章节)和实体报头(第7.1章节)字段，遵循相同的通用格式，在RFC 822 第 3.1 章节中给出。每个报头字段由一个名称后面紧跟一个冒号( : )、一个空格(SP)字符和字段值组成。字段名不区分大小写。报头字段可以扩展到多行，每个额外的行前面至少有一个SP或HT，但不建议这样做。

报头字段接收的顺序是不重要的。但是，"最好"先发送通用报头字段，然后再发送实体报头字段之前的请求报头或响应报头字段。

当且仅当该报头字段的整个字段值被定义为一个逗号分隔的列表[即#(values)]时，多个具有相同字段名的 http 报头字段可能出现在消息中。必须能够将多个标头字段组合成一个"字段名称：字段-值"对，而无需更改消息的语义，方法是将每个后续字段附加到第一个字段值，每个字段值用逗号分隔。

3、一般头字段

有一些报头字段对请求和响应消息具有一般适用性，但不适用于正在传输的实体。这些标头仅适用于正在传输的消息。

通用报头字段名只能与协议版本的变化相结合进行可靠扩展。但是，如果通信中的所有各方都认识到新的或实验性的标头字段是常规标头字段，则可以为它们指定常规标头字段的语义。无法识别的标头字段被视为实体标头字段。

五、请求

从客户端到服务器的请求消息在该消息的第一行中包括要应用于资源的方法、资源的标识符以及正在使用的协议版本。为了向后兼容更有限的 HTTP/0.9 协议，HTTP 请求有两种有效格式：

如果 HTTP/1.0 服务器收到简单请求，它必须使用 HTTP/0.9 简单响应进行响应。能够接收完整响应的 HTTP/1.0 客户端永远不应生成简单请求。

1、请求行

请求行以方法令牌开头，后跟请求 URI 和协议版本，并以 CRLF 结尾。这些元素由 SP 字符分隔。除最终的 CRLF 序列外，不允许使用 CR 或 LF。

请注意，简单请求和完整请求的请求线之间的区别在于 HTTP 版本字段的存在以及 GET 以外的方法的可用性。

1、方法

方法令牌指示要对请求 URI 标识的资源执行的方法。该方法区分大小写。

特定资源可接受的方法列表可以动态更改；如果某个资源上不允许使用某个方法，则通过响应的返回代码通知客户端。如果无法识别或未实现该方法，则服务器应返回状态代码 501（未实现）。

HTTP/1.0应用程序常用的方法在第8节中有完整的定义。

2、请求 URI

Request-URI 是一个统一的资源标识符（第 3.2 节），用于标识应用请求的资源。

请求 URI 的两个选项取决于请求的性质。

仅当向代理发出请求时，才允许使用绝对URI表单。请求代理转发请求并返回响应。如果请求是 GET 或 HEAD，并且缓存了先前的响应，则代理可能会使用缓存的消息，如果它通过了 Expires 标头字段中的任何限制。请注意，代理可以将请求转发到另一个代理，也可以直接转发到 absoluteURI 指定的服务器。为了避免请求循环，代理必须能够识别其所有服务器名称，包括任何别名、本地变体和数字 IP 地址。一个示例请求行是：

最常见的请求 URI 形式是用于标识源服务器或网关上的资源。在这种情况下，仅传输 URI 的绝对路径（请参见第 3.2.1 节， abs_path）。例如，希望直接从源服务器检索上述资源的客户端将创建与主机" www.w3.org"的端口 80 的 TCP 连接，并发送以下行：

然后是完整请求的其余部分。请注意，绝对路径不能为空；

请求 URI 作为编码字符串传输，其中某些字符可以使用 RFC 1738 [4] 定义的"% HEX HEX"编码进行转义。源服务器必须对请求 URI 进行解码，才能正确解释请求。

2、请求头字段

请求报头字段允许客户端向服务器传递关于请求和客户端本身的附加信息。这些字段充当请求修饰符，其语义等效于编程语言方法（过程）调用的参数。

请求报文头字段名称只能与协议版本的更改结合使用才能可靠地扩展。然而，如果通信中的所有各方都认识到它们是请求报头字段，新的或实验报头字段可能被赋予请求报头字段的语义。未识别的报头字段被视为实体报头字段。

六、响应

服务器接收并解释请求消息后，以 HTTP 响应消息的形式进行响应。


简单响应应仅在响应 HTTP/0.9 简单请求时发送，或者当服务器仅支持更有限的 HTTP/0.9 协议时发送。如果客户端发送 HTTP/1.0 完整请求并收到不以状态行开头的响应，则应假定该响应是简单响应并相应地对其进行分析。请注意，简单响应仅由实体正文组成，并由关闭连接的服务器终止。

1、 状态行

完整响应消息的第一行是状态行，由协议版本后跟数字状态代码及其关联的文本短语组成，每个元素由 SP 字符分隔。除最终的 CRLF 序列外，不允许使用 CR 或 LF。

由于状态行始终以协议版本和状态代码开头。

（例如，“HTTP/1.0 200”），该表达式的存在足以区分完整响应和简单响应。尽管简单响应格式可能允许在实体正文的开头出现这样的表达式，因此，如果消息是在响应 Full-Request 时给出的，则会导致对消息的误解，但大多数 HTTP/0.9 服务器仅限于"text/html"类型的响应，因此永远不会生成此类响应。

1、状态代码和原因短语

状态代码元素是尝试理解和满足请求的 3 位整数结果代码。原因短语旨在提供状态代码的简短文本描述。状态代码旨在供自动机使用，原因短语适用于人类用户。客户端不需要检查或显示原因短语。

状态代码的第一个数字定义了响应的类。最后两位数字没有任何分类角色。第一个数字有 5 个值：

• 1xx：信息 - 未使用，但保留以备将来使用。

• 2xx：成功 - 操作已成功接收、理解和接受。

• 3xx：重定向 - 必须采取进一步措施才能完成请求。

• 4xx：客户端错误 - 请求包含错误的语法或无法满足。

• 5xx：服务器错误 - 服务器无法满足明显有效的请求。

下面介绍了为 HTTP/1.0 定义的数字状态代码的各个值，以及相应的 Reason-Phrase 的示例集。此处列出的原因短语仅建议使用 - 它们可以被本地等效短语替换，而不会影响协议。这些代码在第 9 节中已完全定义。

HTTP状态代码是可扩展的，但上述代码是当前实践中唯一普遍认可的代码。HTTP应用程序不需要理解所有注册状态码的含义，尽管这种理解显然是需要的。但是，应用程序必须了解任何状态代码的类（如第一位数字所示），并将任何无法识别的响应视为等效于该类的 x00 状态代码，但不能缓存无法识别的响应。例如，如果客户端收到无法识别的状态代码 431，它可以安全地假定其请求有问题，并将响应视为已收到 400 状态代码。在这种情况下，用户代理应向用户显示随响应一起返回的实体，因为该实体可能包含人类可读的信息，这些信息将解释异常状态。

2、响应头字段

响应标头字段允许服务器传递有关响应的其他信息，这些信息不能放在状态行中。这些报头字段提供了关于服务器的信息，以及关于进一步访问由Request-URI标识的资源的信息。

响应标头字段名称只能与协议版本的更改结合使用才能可靠地扩展。但是，如果通信中的所有各方都认识到新的或实验性的标头字段是响应标头字段，则可以为这些字段指定响应标头字段的语义。无法识别的标头字段被视为实体标头字段。

七、实体

"完全请求"和"完全响应"消息可能会在某些请求和响应中传输实体。一个实体由实体头字段和(通常)实体体组成。在本节中，发送方和接收方都指客户端或服务器，这取决于谁发送和谁接收实体。

1、实体头字段

"实体标头"字段定义有关实体正文的可选信息，或者，如果不存在正文，则定义有关请求所标识的资源的可选信息。

扩展标头机制允许在不更改协议的情况下定义其他实体标头字段，但不能假定这些字段可由收件人识别。无法识别的标头字段应由收件人忽略，并由代理转发。

2、实体主体

随 HTTP 请求或响应一起发送的实体正文（如果有）采用由"实体标头"字段定义的格式和编码。

仅当请求方法调用实体正文时，实体正文才会包含在请求消息中。请求中实体正文的存在通过在请求消息标头中包含内容长度标头字段来发出信号。包含实体正文的 HTTP/1.0 请求必须包含有效的"内容长度"标头字段。

对于响应消息，实体正文是否包含在消息中取决于请求方法和响应代码。对 HEAD 请求方法的所有响应都不得包含正文，即使实体标头字段的存在可能会导致人们相信它们包含正文。所有 1xx（信息性）、204（无内容）和 304（未修改）响应不得包含正文。所有其他响应必须包括实体正文或用值为零 （0） 定义的内容长度标头字段。

1、类型

当实体正文包含在消息中时，该正文的数据类型将通过标头字段"内容类型"和"内容编码"确定。它们定义了一个双层有序编码模型：

内容类型指定基础数据的媒体类型。内容编码可用于指示应用于类型的任何其他内容编码，通常用于数据压缩，这是所请求资源的属性。内容编码的默认值为 none（即标识函数）。

任何包含实体正文的 HTTP/1.0 消息都应包含定义该正文的媒体类型的内容类型标头字段。当且仅当媒体类型不是由内容类型标头给出时（如简单响应消息的情况），收件人可能会尝试通过检查其内容和/或用于标识资源的 URL 的名称扩展来猜测媒体类型。如果媒体类型仍然未知，则收件人应将其视为类型"应用程序/八位字节流"。

2、长度

当实体正文包含在消息中时，可以通过以下两种方式之一确定该正文的长度。如果存在"内容长度"标头字段，则其值（以字节为单位）表示实体正文的长度。否则，主体长度由服务器关闭连接确定。

关闭连接不能用于指示请求正文的结束，因为服务器无法发回响应。因此，包含实体正文的 HTTP/1.0 请求必须包含有效的内容长度标头字段。如果请求包含实体正文，并且未指定 Content-Length，并且服务器无法识别或无法从其他字段计算长度，则服务器应发送 400（错误请求）响应。

注：某些较旧的服务器在发送包含动态插入到数据流的服务器端包含的文档时提供无效的内容长度。必须强调的是，未来版本的HTTP不会容忍这一点。除非客户端知道它正在接收来自兼容服务器的响应，否则它不应依赖于 Content-Length 值是否正确。

八、方法定义

下面定义了 HTTP/1.0 的常用方法集。尽管可以扩展此集，但对于单独扩展的客户端和服务器，不能假定其他方法共享相同的语义。

1、GET

GET 方法意味着检索由 Request-URI 标识的任何信息（以实体的形式）。如果 Request-URI 引用数据生成过程，则生成的数据应作为响应中的实体返回，而不是过程的源文本，除非该文本恰好是该过程的输出。

如果请求消息包含 If-Modified-Since 标头字段，则 GET 方法的语义将更改为"条件 GET"。条件 GET 方法请求仅当所标识的资源自 If-Modified-Since 标头给出的日期以来进行了修改时，才进行传输，如第 10.9 节所述。条件 GET 方法旨在通过允许刷新缓存的实体来减少网络使用量，而无需多个请求或传输不必要的数据。

2、HEAD

HEAD 方法与 GET 相同，只是服务器不得在响应中返回任何实体正文。响应 HEAD 请求的 HTTP 标头中包含的信息应与响应 GET 请求时发送的信息相同。此方法可用于获取有关由请求 URI 标识的资源的信息，而无需传输实体正文本身。此方法通常用于测试超文本链接的有效性、可访问性和最近修改。

没有类似于条件 GET 的"条件 HEAD"请求。如果 HEAD 请求中包含 If-Modified-Since 标头字段，则应忽略该字段。

3、POST

POST 方法用于请求目标服务器接受请求中包含的实体，作为请求行中的请求 URI 标识的资源的新从属项。POST 旨在允许使用统一的方法涵盖以下功能：

• 现有资源的注释；

• 将消息发布到公告板、新闻组、邮件列表或类似的文章组；

• 向数据处理过程提供数据块，例如提交表单的结果；

• 通过追加操作扩展数据库。

由 POST 方法执行的实际功能由服务器确定，通常依赖于请求 URI。已发布实体从属于该 URI，就像文件从属于包含该 URI 的目录、新闻文章从属于发布该 URI 的新闻组或记录从属于数据库一样。

成功的 POST 不需要将实体创建为源服务器上的资源，也不需要使实体可供将来参考。也就是说，POST 方法执行的操作可能不会产生可由 URI 标识的资源。在这种情况下，200（正常）或 204（无内容）是适当的响应状态，具体取决于响应是否包含描述结果的实体。

如果已在源服务器上创建了资源，则响应应为 201（已创建），并包含一个实体（最好是"text/html"类型），该实体描述请求的状态并引用新资源。

所有 HTTP/1.0 POST 请求都需要有效的内容长度。如果 HTTP/1.0 服务器无法确定请求消息内容的长度，则应使用 400（错误请求）消息进行响应。

应用程序不得缓存对 POST 请求的响应，因为应用程序无法知道服务器是否会在将来的某些请求上返回等效响应。

九、状态代码定义

下面介绍了每个状态代码，包括它可以遵循的方法以及响应中所需的任何信息的说明。

1、信息 1xx

此类状态代码指示临时响应，仅由状态行和可选标头组成，并由空行终止。HTTP/1.0 没有定义任何 1xx 状态代码，它们不是对 HTTP/1.0 请求的有效响应。但是，它们可能适用于本规范范围之外的实验应用。

2、成功 2xx

此类状态代码指示客户端的请求已成功接收、理解和接受。

1、200 OK

请求已成功。随响应返回的信息取决于请求中使用的方法，如下所示：

• GET：响应中发送了与请求资源相对应的实体；

• HEAD：响应必须仅包含标头信息，而不包含实体正文；

• POST：描述或包含操作结果的实体。

2、201 Created

请求已得到满足，并导致正在创建新资源。新创建的资源可由响应实体中返回的 URI 引用。源服务器应在使用此状态代码之前创建资源。如果无法立即执行操作，服务器必须在响应正文中包含资源何时可用的描述；否则，服务器应以 202（已接受）进行响应。

在此规范定义的方法中，只有 POST 可以创建资源。

3、202 Accepted

请求已被接受进行处理，但处理尚未完成。该请求最终可能会或可能不会被执行，因为在实际进行处理时，它可能会被禁止。没有用于从这样的异步操作重新发送状态代码的工具。

202 的回应是故意不承诺的。其目的是允许服务器接受对其他进程（可能是每天仅运行一次的面向批处理的进程）的请求，而不要求用户代理与服务器的连接一直保持到进程完成。随此响应返回的实体应包括请求当前状态的指示，以及指向状态监视器的指针或用户预期请求得到满足的时间的一些估计值。

4、204 No Content

服务器已满足请求，但没有要发回的新信息。如果客户端是用户代理，则不应更改其文档视图与导致生成请求的视图。此响应主要用于允许在不导致用户代理的活动文档视图发生更改的情况下执行脚本或其他操作的输入。响应可能包括实体标头形式的新信息，这些内容应应用于当前在用户代理的活动视图中的文档。

3、重定向 3xx

此类状态代码指示用户代理需要采取进一步操作才能满足请求。当且仅当后续请求中使用的方法是 GET 或 HEAD 时，所需的操作可以由用户代理执行，而无需与用户交互。用户代理自动重定向请求的次数不应超过 5 次，因为此类重定向通常表示无限循环。

1、300 Multiple Choices

HTTP/1.0 应用程序不直接使用此响应代码，而是用作解释 3xx 类响应的默认代码。

请求的资源在一个或多个位置可用。

除非是 HEAD 请求，否则响应应包括一个实体，其中包含资源特征和位置的列表，用户或用户代理可以从中选择最合适的资源特征和位置。如果服务器有首选选项，则应在"位置"字段中包含 URL;用户代理可以使用此字段值进行自动重定向。

2、301 Moved Permanently

已为请求的资源分配了一个新的永久 URL，将来对此资源的任何引用都应使用该 URL 完成。具有链接编辑功能的客户端应尽可能自动将对 Request-URI 的引用重新链接到服务器返回的新引用。

新 URL 必须由响应中的"位置"字段提供。除非是 HEAD 请求，否则响应的实体正文应包含一个简短的注释，其中包含指向新 URL 的超链接。

如果使用 POST 方法响应请求时收到 301 状态代码，则用户代理不得自动重定向请求，除非用户可以确认该请求，因为这可能会更改发出请求的条件。

注：在收到 301 状态代码后自动重定向 POST 请求时，某些现有用户代理会错误地将其更改为 GET 请求。

3、302 Moved Temporarily

请求的资源暂时驻留在不同的 URL 下。由于重定向有时可能会更改，因此客户端应继续对将来的请求使用请求 URI。

URL 必须由响应中的"位置"字段提供。除非是 HEAD 请求，否则响应的实体正文应包含一个简短的注释，其中包含指向新 URI 的超链接。

如果使用 POST 方法响应请求时收到 302 状态代码，则用户代理不得自动重定向请求，除非用户可以确认，因为这可能会更改发出请求的条件。

注：在收到 302 状态代码后自动重定向 POST 请求时，某些现有用户代理会错误地将其更改为 GET 请求。

4、304 Not Modified

如果客户端已执行条件 GET 请求并允许访问，但自"如果修改时间"字段中指定的日期和时间以来未修改文档，则服务器必须使用此状态代码进行响应，并且不会向客户端发送实体正文。响应中包含的标头字段应仅包含与缓存管理器相关的信息，或者可能已独立于实体的上次修改日期而更改的信息。相关标头字段的示例包括：“日期”、“服务器"和"过期”。缓存应更新其缓存实体，以反映 304 响应中给出的任何新字段值。

4、客户端错误 4xx

4xx 类状态代码适用于客户端似乎出错的情况。如果客户端在收到 4xx 代码时尚未完成请求，则应立即停止向服务器发送数据。除非响应 HEAD 请求，否则服务器应包含一个实体，其中包含错误情况的解释，以及它是临时条件还是永久条件。这些状态代码适用于任何请求方法。

注：如果客户端正在发送数据，则 TCP 上的服务器实现应小心，以确保客户端在关闭输入连接之前确认收到包含响应的数据包。如果客户端在关闭后继续向服务器发送数据，则服务器的控制器将向客户端发送重置数据包，这可能会擦除客户端未确认的输入缓冲区，然后才能被 HTTP 应用程序读取和解释。

1、400 Bad Request

由于语法格式错误，服务器无法理解该请求。客户端不应在未进行修改的情况下重复请求。

2、401 Unauthorized

该请求需要用户身份验证。响应必须包含一个 WWW 身份验证标头字段（第 10.16 节），其中包含适用于所请求资源的质询。客户端可以使用合适的授权标头字段重复请求（第 10.2 节）。如果请求已包含授权凭据，则 401 响应指示已拒绝对这些凭据的授权。如果 401 响应包含与先前响应相同的质询，并且用户代理已尝试至少一次身份验证，则应向用户显示响应中给出的实体，因为该实体可能包含相关的诊断信息。因为该实体可能包括相关的诊断信息。第 11 节对 HTTP 访问身份验证进行了说明。

3、403 Forbidden

服务器理解该请求，但拒绝满足该请求。授权无济于事，请求不应重复。如果请求方法不是 HEAD，并且服务器希望公开请求未得到满足的原因，则应在实体正文中描述拒绝的原因。当服务器不希望确切地显示请求被拒绝的原因，或者没有其他响应适用时，通常使用此状态代码。

4、404 Not Found

服务器未找到与请求 URI 匹配的任何内容。没有说明该病症是暂时的还是永久性的。如果服务器不希望将此信息提供给客户端，则可以改用状态代码 403（禁止）。

5、服务端错误 5xx

以数字"5"开头的响应状态代码表示服务器知道它已出错或无法执行请求的情况。如果客户端在收到 5xx 代码时尚未完成请求，则应立即停止向服务器发送数据。除非响应 HEAD 请求，否则服务器应包含一个实体，其中包含错误情况的解释，以及它是临时条件还是永久条件。这些响应代码适用于任何请求方法，并且没有必需的标头字段。

1、500 Internal Server Error

服务器遇到意外情况，导致无法满足请求。

2、501 Not Implemented

服务器不支持满足请求所需的功能。当服务器无法识别请求方法并且无法为任何资源支持该方法时，这是适当的响应。

3、502 Bad Gateway

服务器在充当网关或代理时，从尝试满足请求时访问的上游服务器收到了无效响应。

4、503 Service Unavailable

由于服务器的临时过载或维护，服务器当前无法处理请求。这意味着这是一个暂时的情况，在一些延迟后将得到缓解。

注：503 状态代码的存在并不意味着服务器在过载时必须使用它。某些服务器可能希望简单地拒绝连接。

十、头字段定义

本节定义所有常用 HTTP/1.0 标头字段的语法和语义。对于常规和实体标头字段，发件人和收件人都引用客户端或服务器，具体取决于发送和接收邮件的人员。

1、Allow

"允许实体标头"字段列出了由请求 URI 标识的资源支持的方法集。此字段的用途严格用于通知收件人与资源关联的有效方法。在使用 POST 方法的请求中不允许使用 Allow 标头字段，因此，如果将其作为 POST 实体的一部分接收，则应忽略该字段。

此字段无法阻止客户端尝试其他方法。但是，应遵循"允许"标头字段值给出的指示。允许的方法的实际集由源服务器在每个请求时定义。

代理不得修改"允许"标头字段，即使它不理解所有指定的方法，因为用户代理可能具有与源服务器通信的其他方式。

"允许"标头字段不指示服务器实现的方法。

2、Authorization

希望通过服务器对自身进行身份验证的用户代理（通常但不一定在收到 401 响应后）可以通过在请求中包含授权请求标头字段来执行此操作。"授权"字段值由凭据组成，这些凭据包含所请求资源领域的用户代理的身份验证信息。

第 11 节介绍了 HTTP 访问身份验证。如果请求经过身份验证并指定了域，则相同的凭据应对该域中的所有其他请求有效。

对包含授权字段的请求的响应不可缓存。

3、Content-Encoding

"内容编码实体标头"字段用作媒体类型的修饰符。如果存在，则其值指示已向资源应用了哪些附加内容编码，从而必须应用何种解码机制才能获取 Content-Type 标头字段引用的媒体类型。内容编码主要用于允许在不丢失其基础媒体类型标识的情况下压缩文档。

内容编码在第 3.5 节中定义。其使用的一个例子是：

内容编码是由请求 URI 标识的资源的特征。通常，资源使用此编码存储，并且仅在呈现或类似用法之前进行解码。

4、Content-Length

"内容长度"实体标头字段指示发送给收件人的实体正文的大小（以十进制八位字节为单位），或者，对于 HEAD 方法，则指示如果请求是 GET，则本应发送的实体正文的大小。

应用程序应使用此字段来指示要传输的实体正文的大小，而不管实体的媒体类型如何。包含实体正文的所有 HTTP/1.0 请求消息都需要有效的"内容长度"字段值。

任何大于或等于零的内容长度都是有效值。第 7.2.2 节描述了如何在未给出内容长度的情况下确定响应实体正文的长度。

注：此字段的含义与 MIME 中的相应定义明显不同，MIME 中的相应定义是在"邮件/外部正文"内容类型中使用的可选字段。在 HTTP 中，只要在传输之前可以确定实体的长度，就应该使用它。

5、Content-Type

"内容类型实体标头"字段指示发送给收件人的实体正文的媒体类型，或者，对于 HEAD 方法，则指示如果请求是 GET，则本应发送的媒体类型。

介质类型在第 3.6 节中定义。该字段的一个示例是：

第 7.2.1 节进一步讨论了识别实体的介质类型的方法。

6、Date

"日期常规标头"字段表示消息发出的日期和时间，其语义与 RFC 822 中的 orig-date 相同。字段值是 HTTP 日期，如第 3.3 节所述。

如果通过与用户代理（在请求的情况下）或源服务器（在响应的情况下）的直接连接接收消息，则可以假定该日期是接收端的当前日期。但是，由于日期（正如源所认为的那样）对于评估缓存的响应非常重要，因此源服务器应始终包含 Date 标头。客户端应仅在包含实体正文的邮件中发送 Date 标头字段，如 POST 请求的情况，即使这样，它也是可选的。如果没有 Date 标头字段的已接收邮件将由该收件人缓存或通过需要 Date 的协议进行网关处理，则该邮件应由收件人分配一个。

从理论上讲，日期应表示生成实体之前的时刻。实际上，日期可以在消息发出期间的任何时间生成，而不会影响其语义值。

注：此文档的早期版本错误地指定此字段应包含所附实体正文的创建日期。这已被更改以反映实际（和正确）用法。

7、Expires

"过期实体标头"字段提供了应将实体视为过时的日期/时间。这允许信息提供者建议资源的波动性，或者信息可能不再有效的日期。应用程序不得将此实体缓存到给定日期之后。Expires 字段的存在并不意味着原始资源将在该时间、之前或之后更改或停止存在。但是，知道甚至怀疑资源将在特定日期更改的信息提供者应包含具有该日期的 Expire 标头。格式是绝对日期和时间，由第 3.3 节中的 HTTP 日期定义。

如果给定的日期等于或早于 Date 标头的值，则收件人不得缓存封闭的实体。如果资源本质上是动态的，就像许多数据生成过程一样，则应为该资源中的实体提供适当的 Expires 值，以反映该动态。

"过期"字段不能用于强制用户代理刷新其显示或重新加载资源。其语义仅适用于缓存机制，并且此类机制只需在启动对资源的新请求时检查该资源的过期状态。

用户代理通常具有历史记录机制，例如"后退"按钮和历史记录列表，可用于重新显示会话中较早检索到的实体。默认情况下，"过期"字段不适用于历史记录机制。如果实体仍在存储中，则即使实体已过期，历史记录机制也应显示它，除非用户已专门将代理配置为刷新过期的历史记录文档。

注：鼓励应用程序容忍 Expires 标头的错误或错误信息实现。值为零 （0） 或无效的日期格式应被视为等效于"立即过期"。尽管这些值对于 HTTP/1.0 不合法，但始终需要可靠的实现。

8、From

如果给出了From请求头字段，则应该包含控制请求用户代理的人类用户的互联网电子邮件地址。该地址应为计算机可用，如 RFC 822 中的邮箱所定义（由 RFC 1123 更新）：

此标头字段可用于日志记录目的，并用作标识无效或不需要的请求的来源的方法。它不应用作不安全的访问保护形式。此字段的解释是，请求是代表给定的人员执行的，该人员接受对所执行方法的责任。特别是，机器人代理应包含此标头，以便在接收端出现问题时可以联系负责运行机器人的人员。

此字段中的互联网电子邮件地址可能与发出请求的互联网主机分开。例如，当请求通过代理传递时，应使用原始颁发者的地址。

注：未经用户批准，客户端不应发送 From 标头字段，因为它可能与用户的隐私利益或其网站的安全策略相冲突。强烈建议用户在发出请求之前随时禁用、启用和修改此字段的值。

9、If-Modified-Since

If-Modified-Since 请求标头字段与 GET 方法一起使用，以使其有条件：如果请求的资源在此字段中指定的时间内未被修改，则不会从服务器返回资源的副本；相反，将返回 304（未修改）响应，而不返回任何实体正文。

条件 GET 方法请求仅当自 If-Modified-Since 标头给出的日期以来已对其进行修改时，才传输已标识的资源。用于确定此问题的算法包括以下情况：

• 如果请求通常会导致 200 （ok） 状态以外的任何内容，或者如果传递的 If-Modified-Since 日期无效，则响应与普通 GET 完全相同。晚于服务器当前时间的日期无效。

• 如果资源自"如果修改时间"日期以来已被修改，则响应与普通 GET 完全相同。

• 如果资源自有效的 If-Modified-From 日期以来未被修改，则服务器应返回 304（未修改）响应。

此功能的目的是允许以最小的事务开销高效更新缓存的信息。

10、Last-Modified

"上次修改时间"实体标头字段指示发件人认为上次修改资源的日期和时间。此字段的确切语义根据收件人应如何解释它来定义：如果收件人拥有此资源的副本早于"上次修改时间"字段给出的日期，则该副本应被视为过时。

这个报头字段的确切含义取决于发送方的实现和原始资源的性质。对于文件，它可能只是文件系统上次修改的时间。对于具有动态包含部件的实体，它可能是其组件部件的上次修改时间集中的最近一次。对于数据库网关，它可能是记录的上次更新时间戳。对于虚拟对象，这可能是内部状态最后一次更改。

源服务器发送的上次修改日期不得晚于服务器的消息发出时间。在这种情况下，如果资源的最后一次修改将指示将来的某个时间，则服务器必须将该日期替换为消息发出日期。

11、Location

"位置响应标头"字段定义由请求 URI 标识的资源的确切位置。对于 3xx 响应，位置必须指示服务器的首选 URL，以便自动重定向到资源。只允许一个绝对 URL。

12、Pragma

Pragma 常规标头字段用于包含可能应用于请求/响应链上任何收件人的实现特定指令。所有编译指示都从协议的角度指定可选行为；但是，某些系统可能要求行为与指令一致。

当请求消息中存在"no-cache"指令时，应用程序应将请求转发到源服务器，即使它具有所请求内容的缓存副本。这允许客户坚持要求收到对其请求的权威响应。它还允许客户端刷新已知已损坏或过时的缓存副本。

Pragma 指令必须由代理或网关应用程序传递，无论它们对该应用程序的重要性如何，因为这些指令可能适用于请求/响应链上的所有收件人。无法为特定收件人指定编译指示;但是，任何与收件人无关的编译指示都应被该收件人忽略。

13、Referer

"引用程序请求标头"字段允许客户端指定从中获取请求 URI 的资源的地址 （URI），这对服务器有利。这允许服务器生成指向感兴趣的资源的反向链接列表，以进行日志记录，优化缓存等。它还允许跟踪过时或键入错误的链接以进行维护。如果 Request-URI 是从没有自己的 URI 的源（如来自用户键盘的输入）获取的，则不得发送引用方字段。

如果给出了部分 URI，则应相对于请求 URI 对其进行解释。URI 不得包含片段。

注：由于链接的来源可能是私人信息，也可能泄露其他私人信息来源，因此强烈建议用户能够选择是否发送"引用者"字段。例如，浏览器客户端可以有一个用于公开/匿名浏览的切换开关，这将分别启用/禁用"引用"和"发件人"信息的发送。

14、Server

服务器响应标头字段包含有关源服务器用于处理请求的软件的信息。该字段可以包含多个产品令牌（第 3.7 节）和标识服务器和任何重要子产品的注释。按照惯例，产品令牌按其标识应用程序的显著性顺序列出。

如果通过代理转发响应，则代理应用程序不得将其数据添加到产品列表中。

注：显示服务器的特定软件版本可能会使服务器计算机更容易受到针对已知包含安全漏洞的软件的攻击。鼓励服务器实现者将此字段设置为可配置选项。鼓励服务器实现者将此字段设置为可配置选项。

注：某些现有服务器无法将自己限制为"服务器"字段中的产品令牌语法。

15、User-Agent

用户代理请求标头字段包含有关发起请求的用户代理的信息。这是出于统计目的，跟踪协议违规以及自动识别用户代理，以便定制响应以避免特定的用户代理限制。尽管不是必需的，但用户代理应在请求中包含此字段。该字段可以包含多个产品令牌（第 3.7 节）和注释，用于标识代理和构成用户代理重要部分的任何子产品。按照惯例，产品令牌按其标识应用程序的显著性顺序列出。

注：某些当前代理应用程序将其产品信息追加到"用户代理"字段中的列表中。不建议这样做，因为这会使这些字段的机器解释变得模棱两可。

注：某些现有客户端无法将自己限制为"用户代理"字段中的产品令牌语法。

16、WWW-Authenticate

"WWW 身份验证"响应标头字段必须包含在 401（未经授权的）响应消息中。该字段值至少包含一个质询，该质询指示适用于请求 URI 的身份验证方案和参数。

第 11 节介绍了 HTTP 访问身份验证过程。如果 WWW-Authenticate 字段值包含多个质询，或者提供了多个 WWW-Authenticate 标头字段，则用户代理在分析该字段值时必须特别小心，因为质询的内容本身可能包含以逗号分隔的身份验证参数列表。

十一、访问鉴别

HTTP 提供了一种简单的质询-响应身份验证机制，服务器可以使用该机制对客户端请求进行质询，客户端可以使用该机制来提供身份验证信息。它使用可扩展的、不区分大小写的令牌来标识身份验证方案，后跟一个以逗号分隔的属性-值对列表，这些属性-值对携带通过该方案实现身份验证所需的参数。

源服务器使用 401（未经授权的）响应消息来质询用户代理的授权。此响应必须包含一个 WWW 身份验证标头字段，其中包含至少一个适用于所请求资源的质询。

对于发出质询的所有身份验证方案，都需要 realm 属性（不区分大小写）。领域值（区分大小写）与所访问服务器的规范根 URL 相结合，定义了保护空间。这些领域允许将服务器上的受保护资源分区为一组保护空间，每个空间都有自己的认证方案和/或授权数据库。领域值是一个字符串，通常由源服务器分配，它可能具有特定于身份验证方案的其他语义。

希望使用服务器对自身进行身份验证的用户代理（通常但不一定在收到 401 响应后）可以通过在请求中包含授权标头字段来执行此操作。"授权"字段值由凭据组成，这些凭据包含所请求资源领域的用户代理的身份验证信息。

用户代理可以自动应用凭据的域由保护空间确定。如果先前的请求已获得授权，则在由身份验证方案、参数和/或用户首选项确定的一段时间内，相同的凭据可以重用于该保护空间内的所有其他请求。

除非身份验证方案另有定义，否则单个保护空间不能扩展到其服务器范围之外。

如果服务器不希望接受随请求发送的凭据，则应返回 403（禁止）响应。

HTTP 协议不会将应用程序限制为这种简单的质询-响应机制进行访问身份验证。可以使用其他机制，例如在传输级别或通过消息封装进行加密，以及使用指定身份验证信息的其他标头字段。但是，本规范未定义这些附加机制。

代理在用户代理身份验证方面必须完全透明。也就是说，它们必须原封不动地转发 WWW 身份验证和授权标头，并且不得缓存对包含授权的请求的响应。HTTP/1.0 没有为客户端提供使用代理进行身份验证的方法。

1、基本认证方案

"基本"认证方案基于以下模型：用户代理必须使用每个域的用户标识和密码对自身进行身份验证。领域值应被视为不透明字符串，只能与该服务器上的其他领域进行比较。仅当服务器可以验证请求 URI 保护空间的用户 ID 和密码时，服务器才会对请求进行授权。没有可选的身份验证参数。

在收到对保护空间内的 URI 的未经授权的请求后，服务器应以如下所示的质询进行响应：

其中"WallyWorld"是服务器分配的字符串，用于标识 Request-URI 的保护空间。

为了接收授权，客户端在凭证中的 base64 编码字符串中发送用户 ID 和密码（以单个冒号 （"："） 字符分隔）。

如果用户代理希望发送用户 ID"阿拉丁"和密码"打开芝麻"，它将使用以下标头字段：

基本身份验证方案是一种非安全方法，用于筛选对 HTTP 服务器上资源的未经授权的访问。它基于这样的假设，即客户端和服务器之间的连接可以被视为受信任的载体。由于这在开放网络上通常不适用，因此应相应地使用基本身份验证方案。尽管如此，客户端仍应实现该方案，以便与使用它的服务器进行通信。

十二、安全注意事项

本节旨在告知应用程序开发人员、信息提供者和用户 HTTP/1.0 中的安全限制，如本文档所述。讨论不包括对所揭示的问题的最终解决方案，尽管它确实提出了一些降低安全风险的建议。

1、客户端身份验证

如第 11.1 节所述，基本身份验证方案不是用户身份验证的安全方法，也不会阻止实体体在用作载体的物理网络中以明文形式传输。HTTP/1.0 不会阻止使用其他身份验证方案和加密机制来提高安全性。

2、安全方法

客户端软件的作者应该意识到该软件在用户通过互联网进行的交互中代表了用户，并且应该小心地让用户意识到他们可能采取的任何可能对自己或他人具有意想不到的意义的操作。

特别是，已经确立了 GET 和 HEAD 方法永远不应具有执行检索以外的操作的重要性。这些方法应被视为"安全"。这允许用户代理以特殊方式表示其他方法（如 POST），以便使用户知道正在请求可能不安全的操作。

当然，不可能确保服务器不会因执行 GET 请求而产生副作用。实际上，一些动态资源认为这是一个功能。这里重要的区别在于，用户没有请求副作用，因此不能对它们负责。

3、滥用服务器日志信息

服务器可以保存有关用户请求的个人数据，这些数据可以识别他们的阅读模式或感兴趣的主题。这些信息显然是保密的，其处理可能受到某些国家/地区的法律限制。使用HTTP协议提供数据的人员有责任确保未经发布结果可识别的任何个人的许可，不会分发此类材料。

4、敏感信息的传输

与任何通用数据传输协议一样，HTTP无法调节所传输数据的内容，也没有任何先验方法在任何给定请求的上下文中确定任何特定信息的敏感性。因此，应用程序应向该信息的提供者提供对此信息的尽可能多的控制。在此上下文中，有三个标头字段特别值得一提：服务器、引用站点和发件人。

显示服务器的特定软件版本可能会使服务器计算机更容易受到针对已知包含安全漏洞的软件的攻击。实现者应使服务器标头字段成为可配置的选项。

"引用者"字段允许研究读取模式并绘制反向链接。尽管它可能非常有用，但如果用户详细信息未与引用者中包含的信息分开，则其功能可能会被滥用。即使个人信息已被删除，"引用者"字段也可能指示不宜发布的私人文档的 URI。

在"发件人"字段中发送的信息可能与用户的隐私兴趣或其网站的安全策略相冲突，因此，在用户无法禁用、启用和修改字段内容的情况下，不应传输这些信息。用户必须能够在用户首选项或应用程序默认配置中设置此字段的内容。

我们建议（尽管不要求）为用户提供一个方便的切换界面，以启用或禁用发件人和转介人信息的发送。

5、基于文件和路径名的攻击

HTTP 源服务器的实现应小心地将 HTTP 请求返回的文档限制为仅是服务器管理员预期的文档。如果 HTTP 服务器将 HTTP URI 直接转换为文件系统调用，则服务器必须特别注意不要提供不打算传递到 HTTP 客户端的文件。例如，Unix、Microsoft Windows 和其他操作系统使用"…"作为路径组件来指示高于当前目录级别的目录级别。在这样的系统上，如果 HTTP 服务器允许访问旨在通过 HTTP 服务器访问的资源之外的资源，则 HTTP 服务器必须禁止 Request-URI 中的任何此类构造。同样，必须保护仅用于在服务器内部引用的文件（如访问控制文件、配置文件和脚本代码），以防止不适当的检索，因为它们可能包含敏感信息。经验表明，此类HTTP服务器实现中的小错误已转化为安全风险。

十三、感谢

十四、参考

十五、作者地址

十六、附录