超文本传输协议 -- HTTP/1.1（一）

• 声明
• 备忘录状态
• 摘要
• 1. 介绍
• • 1.1 目标
  • 1.2 需求
  • 1.3 术语
  • 1.4 概述
• 2. 符号约定和一般语法
• • 2.1 扩展的巴科斯范式
  • 2.2 基本规则
• 3. 协议参数
• • 3.1 HTTP版本
  • 3.2 统一资源标识符（URI）
  • • 3.2.1 一般语法
    • 3.2.2 Http URL
    • 3.2.3 URI对比
  • 3.3 日期/时间格式
  • • 3.3.1 全日期格式
    • 3.3.2 增量秒
  • 3.4 字符集
  • • 3.4.1 丢失字符集
  • 3.5 内容编码
  • 3.6 传输编码
  • • 3.6.1 分块传输码
  • 3.7 媒体类型
  • • 3.7.1 规范及默认文本
    • 3.7.2 多实体类型（Multipart Types）
  • 3.8 产品令牌（Product Tokens）
  • 3.9 权重（Quality Values）
  • 3.10 语言标签（Language Tags）
  • 3.11 实体标签（Entity Tags）
  • 3.12 范围单元（Range Units）
• 4. HTTP消息
• • 4.1 消息类型
  • 4.2 消息头
  • 4.3 消息体（message-body）
  • 4.4 消息长度
  • 4.5 通用头字段（general-header fields）
• 5. 请求
• • 5.1 请求行
  • • 5.1.1 方法
    • 5.1.2 请求URI
  • 5.2 请求标识的资源
  • 5.3 请求头字段
• 6. 响应
• • 6.1 状态行
  • • 6.1.1 状态码（Status-Code）和原因短语（Reason-Phrase）
  • 6.2 响应头字段
• 7. 实体
• • 7.1 实体头字段
  • 7.2 实体体
  • • 7.2.1 类型
    • 7.2.2 实体长度
• 8. 连接
• • 8.1 持久化连接
  • • 8.1.1 目的
    • 8.1.2 概述
    • • 8.1.2.1 协商
      • 8.1.2.2 管道
    • 8.1.3 代理服务器
    • 8.1.4 实际考虑（Practical Considerations）
  • 8.2 消息传输需求
  • • 8.2.1 持久化连接和流控制
    • 8.2.2 监视错误状态消息的连接
    • 8.2.3 100（继续）状态的使用
    • 8.2.4 服务器过早关闭连接时的客户端行为
• 9. 方法定义
• • 9.1 安全和幂等方法
  • • 9.1.1 安全方法
    • 9.1.2 幂等方法
  • 9.2 OPTIONS
  • 9.3 GET
  • 9.4 HEAD
  • 9.5 POST
  • 9.6 PUT
  • 9.7 DELETE
  • 9.8 TRACE
  • 9.9 CONNECT
• 10. 状态码定义
• • 10.1 1xx 信息
  • • 10.1.1 100 Continue
    • 10.1.2 101 协议切换
  • 10.2 2xx 成功状态码
  • • 10.2.1 200 OK
    • 10.2.2 201 已创建
    • 10.2.3 202 已接受
    • 10.2.4 203 非权威信息
    • 10.2.5 204 无内容
    • 10.2.6 205 重置内容
    • 10.2.7 206 局部内容
  • 10.3 3xx 重定向
  • • 10.3.1 300 多项选择
    • 10.3.2 301 永久移动
    • 10.3.3 302 找到
    • 10.3.4 303 参考其它
    • 10.3.5 304 无修改
    • 10.3.6 305 使用代理
    • 10.3.7 306 未使用
    • 10.3.8 307 临时重定向
  • 10.4 4xx 客户端错误
  • • 10.4.1 400 错误请求（Bad Request）
    • 10.4.2 401 未授权（Unauthorized）
    • 10.4.3 402 需要支付（Payment Required）
    • 10.4.4 403 禁止（Forbidden）
    • 10.4.5 404 找不到（Not Found）
    • 10.4.6 405 方法不允许（Method Not Allowed）
    • 10.4.7 406 不可接受（Not Acceptable）
    • 10.4.8 407 需要代理授权（Proxy Authentication Required）
    • 10.4.9 408 请求超时（Request Timeout）
    • 10.4.10 409 冲突（Conflict）
    • 10.4.11 410 消失（Gone）
    • 10.4.12 411 长度需要（Length Required）
    • 10.4.13 412 前提条件失败（Precondition Failed）
    • 10.4.14 413 请求体太大
    • 10.4.15 414 Request-URI 太长
    • 10.4.16 415 不支持的媒体类型（Unsupported Media Type）
    • 10.4.17 416 请求区间不满足
    • 10.4.18 417
  • 10.5 5xx 服务器错误
  • • 10.5.1 500 内部服务错误
    • 10.5.2 501 未实现
    • 10.5.3 502 网关错误
    • 10.5.4 503 服务不可用
    • 10.5.5 504 网关超时
    • 10.5.6 505 不支持的HTTP版本
• 11. 访问认证
• 12. 内容协商（Content Negotiation）
• • 12.1 服务器驱动协商
  • 12.2 代理驱动协商
  • 12.3 透明协商

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

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

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

       OCTET          = <any 8-bit sequence of data>CHAR           = <any US-ASCII character (octets 0 - 127)>UPALPHA        = <any US-ASCII uppercase letter "A".."Z">LOALPHA        = <any US-ASCII lowercase letter "a".."z">ALPHA          = UPALPHA | LOALPHADIGIT          = <any US-ASCII digit "0".."9">CTL            = <any US-ASCII control character(octets 0 - 31) and DEL (127)>CR             = <US-ASCII CR, carriage return (13)>LF             = <US-ASCII LF, linefeed (10)>SP             = <US-ASCII SP, space (32)>HT             = <US-ASCII HT, horizontal-tab (9)><">            = <US-ASCII double-quote mark (34)>

       CRLF           = CR LF

       LWS            = [CRLF] 1*( SP | HT )

       TEXT           = <any OCTET except CTLs,but including LWS>

       HEX            = "A" | "B" | "C" | "D" | "E" | "F"| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

       token          = 1*<any CHAR except CTLs or separators>separators     = "(" | ")" | "<" | ">" | "@"| "," | ";" | ":" | "\" | <">| "/" | "[" | "]" | "?" | "="| "{" | "}" | SP | HT

       comment        = "(" *( ctext | quoted-pair | comment ) ")"ctext          = <any TEXT excluding "(" and ")">

       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )qdtext         = <any TEXT except <">>

       quoted-pair    = "\" CHAR

3. 协议参数

3.1 HTTP版本

HTTP使用“<major>.<minor>”（主版本.次版本）的数字模式来表示协议的版本。协议版本策略是假定允许消息发送者能够表明消息的格式和理解进一步通信的能力，而不是通信带来的特性。不影响通信行为或只是添加到扩展域值的额外的消息组件不会改变协议的版本号。当增加不会改变一般消息解析算法的特性，而这些特性可能影响到消息语法并暗示消息发送者额外的能力时，"<minor>"的数字就会增加。当协议内消息格式发生变化时，“<major>”的数字就会增加。参考RFC 2145¹⁰获得完整解释。

一个HTTP消息的版本是通过消息第一行的域“HTTP-Version”来表示的。

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

注意，主版本号和次版本号必须被当作单独的数字对待，每个版本号都可能高于单个数字。因此，HTTP/2.4版本低于HTTP/2.13版本，反过来又低于HTTP/12.3版本。以0开头的版本号必须被消息接收者忽略，不能发送。

发送包含HTTP/1.1的“HTTP-Version”的请求或者响应消息的应用必须至少有条件地适应本规范。至少有条件地适应本规范的应用应该在它们的消息中使用HTTP/1.1的“HTTP-Version”，对于任何不兼容HTTP/1.0的消息都必须这样做。关于何时发送指定的HTTP-Version值的详情，参考RFC 2145¹⁰。

对于至少满足最低条件规范的应用的HTTP版本应该是最高的协议版本。

代理和网关应该小心地转发不同协议版本应用的消息。一旦协议版本指定了发送者的协议版本能力，代理或者网关不能用高于实际版本的版本指示器发送消息。如果接收到一个高协议版本的请求，必须要么降低请求版本等级，要么返回错误响应，要么切换到隧道行为（往下游传递，不作处理）。

自RFC 2068出版以来，由于HTTP/1.0代理发现的互操作性问题，缓存代理必须、网关可能、隧道不能将协议版本升级为它们支持的最高级版本。代理或者网关对于这种请求的响应必须使用和请求相等的主版本号协议。

注意：HTTP协议版本的转换可能牵涉到相关协议规定的必须或者禁止的头信息域的改变。

3.2 统一资源标识符（URI）

URI有很多众所周知的名称：WWW地址、通用文档定位符、通用资源定位符和统一资源定位符¹¹与URN¹²的结合。对于HTTP而言，URI只是通过名称、地址和其它特性来标识资源的简单的格式化的字符串。

3.2.1 一般语法

HTTP中的URI可以用绝对值的形式或者跟一些已知的基本的URI相关的形式来表述，这取决于它们所使用的内容。通过绝对的URI总是以一个带冒号的模式名称开头这样的事实来区分这两种表现形式。有关URL语法和语义的限制信息，参考"Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 2396¹³。本规范采用了来自RFC 2396规范中"URI-reference"、“absoluteURI”、 “relativeURI”、“port”、“host”、“abs_path”、 "rel_path"和"authority"的定义。

HTTP协议不会替换URI长度的任何优先限制。服务器必须能够处理它们服务的任何资源的URI，应该能够处理它们提供的基于GET形式的无限长度的URI。如果URI的长度比服务器能够处理（参考10.4.15节）的长度还要长，那么服务器应该返回414（请求URI太长）状态码。

      Note: Servers ought to be cautious about depending on URI lengthsabove 255 bytes, because some older client or proxyimplementations might not properly support these lengths.

3.2.2 Http URL

“http”模式通过HTTP协议定位网络资源。本节为http URL定义指定模式的语法和语义。

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

如果端口为空或者不指定，则假定为80端口。以上的语义就是：服务器上的被标识的资源通过监听指定主机和端口上的TCP连接被定位，请求资源的URI用的是绝对路径（abs_path，参考5.1.2节）。无论何时，只要有可能，都应该避免在URL中使用IP地址。如果URL中没有提供绝对路径（abs_path），而这又是用于请求资源的URI的时候，则必须使用“/”替代。如果代理接收到的主机名称是一个不完全限定的域名，则代理可能将自己的域名添加到接收到的主机名称上面。如果代理接收到的是一个完全限定的域名，就不能更改收到的主机名称。

3.2.3 URI对比

当比较2个URI是否匹配时，客户端应该用大小写敏感的全路径的逐位八位比较，除了以下情况：

        - A port that is empty or not given is equivalent to the defaultport for that URI-reference;- Comparisons of host names MUST be case-insensitive;- Comparisons of scheme names MUST be case-insensitive;- An empty abs_path is equivalent to an abs_path of "/".

除“保留”和“不安全”集合中的字符(请参阅RFC 2396¹³)外，其他字符都等效于它们的"% HEX HEX"编码（意思时可用它们的16进制方式表示）。
例如，以下的URI都是相等的：

      http://abc.com:80/~smith/home.htmlhttp://ABC.com/%7Esmith/home.htmlhttp://ABC.com:/%7esmith/home.html

3.3 日期/时间格式

3.3.1 全日期格式

HTTP应用曾经使用了三种日期/时间戳的形式表示：

      Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

第一种格式是互联网标准格式，代表了RFC 1123（对RFC 822的更新）定义的固定长度的子集。第二种格式是通用的，但是它是基于已经废弃的RFC 850定义的，而且还缺少4位长度的年份表示。HTTP/1.1的客户端和服务端在解析日期时必须要能够接收全部的三种格式（为了兼容HTTP/1.0），尽管它们必须只能生成RFC 1123的日期格式来表示头信息域中的HTTP-data值。更多信息请参考19.3节。

      Note: Recipients of date values are encouraged to be robust inaccepting date values that may have been sent by non-HTTPapplications, as is sometimes the case when retrieving or postingmessages via proxies/gateways to SMTP or NNTP.

所有HTTP日期/时间戳必须用格林威治标准时间（Greenwich Mean Time，GMT）表示，没有例外。对HTTP而言，GMT精确地等于UTC（Coordinated Universal Time，宇宙协调时）。这表明前2种格式已经纳入到用三个字母表示时区的"GMT"格式中了，当读取asctime时也必须假定这一点。HTTP-date是大小写敏感的，而且不能包含语法指定的SP之外的额外的线性空格。

       HTTP-date    = rfc1123-date | rfc850-date | asctime-daterfc1123-date = wkday "," SP date1 SP time SP "GMT"rfc850-date  = weekday "," SP date2 SP time SP "GMT"asctime-date = wkday SP date3 SP time SP 4DIGITdate1        = 2DIGIT SP month SP 4DIGIT; day month year (e.g., 02 Jun 1982)date2        = 2DIGIT "-" month "-" 2DIGIT; day-month-year (e.g., 02-Jun-82)date3        = month SP ( 2DIGIT | ( SP 1DIGIT )); month day (e.g., Jun  2)time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT; 00:00:00 - 23:59:59wkday        = "Mon" | "Tue" | "Wed"| "Thu" | "Fri" | "Sat" | "Sun"weekday      = "Monday" | "Tuesday" | "Wednesday"| "Thursday" | "Friday" | "Saturday" | "Sunday"month        = "Jan" | "Feb" | "Mar" | "Apr"| "May" | "Jun" | "Jul" | "Aug"| "Sep" | "Oct" | "Nov" | "Dec"Note: HTTP requirements for the date/time stamp format apply onlyto their usage within the protocol stream. Clients and servers arenot required to use these formats for user presentation, requestlogging, etc.

3.3.2 增量秒

一些HTTP头字段允许将时间值用接收消息后的整数秒数(decimal格式)表示。

       delta-seconds  = 1*DIGIT

3.4 字符集

HTTP使用了和MIME描述的相同的字符集术语的定义：
本文档中的术语“字符集”是指用一个或者多个表将一个八位序列的字节转换为一个字符串序列的方法。注意，在另一个方向上的无条件转换不是必需的，因为不是所有的字符都可以在给定的字符集中使用，并且一个字符集可以提供多个八位元序列来表示一个特定的字符。本定义假定允许多种字符编码，从简单的单表映射如US-ASCII到如ISO-2022技术的复杂表转换法。然而，与MIME字符集名称有关的定义必须完整地指定字节到字符映射的执行。特别地，不允许使用外部分析信息来确定准确的映射。

注意：术语“字符集”更常见地是作为“字符编码”来使用。然而，自从HTTP和MIME共享注册表之后，重要地是术语也被共享了。

HTTP字符集用不区分大小写的令牌标识。IANA字符集注册表¹⁴定义了令牌的全部集合。

       charset = token

尽管HTTP允许用一个专门的令牌来表示字符集，但是任何来自于IANA字符集注册表中预定义的令牌都必须能够代表注册表中定义的字符集。应用程序应该限制注册表中定义的字符集的使用。

实现者应该意识到IETF¹⁵的字符集需求。

3.4.1 丢失字符集

一些HTTP/1.0的软件一直把没有正确字符参数的Content-Type头信息域理解为“接收者应该猜”。希望战胜这种行为的发送者可以包含一个字符集参数在里面即使原字符集是ISO-8859-1，并且在知道不会困扰接收者的情况下更应该这样做。

不幸地是，一些古老的HTTP/1.0客户端没有用明确的字符参数来正确地处理这种情况。HTTP/1.1的接收者必须尊重发送者提供的字符标签；当最初显示文档的时候，提供了要去“猜”字符的这些用户代理必须使用它们支持的来自于Content-Type的字符集，而不是它们偏好的字符集。参考3.7.1节。

3.5 内容编码

内容编码值表明了已经或者能够用于实体的编码转换方式。内容编码主要用来压缩文档或者其它的不会丢失信息和潜在媒体类型一致性的有用的转换。通常，实体以编码形式存储，直接传输，并且仅由接收方解码。

       content-coding   = token

所有的content-coding内容编码的值是不区分大小写的。HTTP/1.1在Accept-Encoding（14.3节）和Content-Encoding（14.11节）中使用内容编码。尽管内容编码的值描述了内容编码，但更重要的是它指出了移出编码的解码机制。

IANA¹⁶在content-coding值令牌中扮演了一个注册表的角色。起初，注册表包含以下令牌：

• gzip
  文件压缩项目“gzip”产生的一种内容编码格式，在RFC 1952中有所描述。这种格式是一种32位CRC的Lempel-Ziv（LZ77）编码格式。
• compress
  通用UNIX文件压缩项目“compress”产生的内容编码格式。这种格式是一种可适应的Lempel-Ziv-Welch编码格式。

用项目名称来鉴别内容编码格式是不令人满意的，对于未来的编码格式也是不鼓励的。以上两种用项目名称命名编码格式的做法是历史实践的典型代表，不是一个好的设计。为了兼容HTTP早先的实现，应用程序应该考虑使用“x-gzip”和“x-compress”来分别替换“gzip”和“compress”。

• deflate
  RFC 1951描述了在RFC 1950中定义的“zlib”格式与“deflate”压缩机制的结合。
• identity
  默认编码格式。不需要任何转换。content-encoding只能用在Accept-Encoding头中，不应该在Content-Encoding头中使用。

新的content-encoding值令牌应该被注册；为了客户端和服务端之间的互操作性，内容编码算法需要一个新的规范，这个规范应该是公用的，能够适应独立的实现且符合本章定义的内容编码目标。

3.6 传输编码

传输编码被用来表明一种已经、能够或者可能需要适应一种实体的编码转换，以确保网络的安全传输。与内容编码不同的地方在于传输编码是消息而不是源实体的一个属性。

       transfer-coding         = "chunked" | transfer-extensiontransfer-extension      = token *( ";" parameter )

参数是属性/值对的形式。

       parameter               = attribute "=" valueattribute               = tokenvalue                   = token | quoted-string

所有传输编码都是忽略大小写的。HTTP/1.1在TE头（14.39节）和Transfer-Encoding头字段（14.41节）中使用了传输编码。

只要传输编码被用于消息体，编码集中必须包含“chunked”，除非消息因为连接断开而终止。当“chunked”传输编码被使用时，它必须是应用于消息体的最后一个编码。“chunked”传输编码不能在消息体中使用超过1次。这些规则能够使消息接收者确定消息的传输长度。

传输编码与MIME中的内容编码是相似的，其设计的目的在于在超过7位字节的传输服务上进行二进制数据的安全传输。然而，安全传输与净8位的传输协议有不同的关注点。在HTTP协议中，消息体中唯一的不安全因数就在于如何精确地确定消息体的长度，或者基于共享传输的数据加密需求。

互联网数字分配机构（IANA）扮演了一个传输编码注册表的角色。这个注册表包含了这些传输编码：chunked, identity, gzip, compress, deflate。

新的传输编码应该以新的内容编码的注册方式注册。

接收到未知传输编码实体的服务端应该响应501（未实现），并且关闭连接。服务端不能发送传输编码给HTTP/1.0的客户端。

3.6.1 分块传输码

分块编码是为了将消息体进行分块传输，每一个部分都有它自己的长度指示器，尾部包含可选的实体头字段。这样可以允许动态生成的内容和消息接收者用来验证是否收到完整消息的必要的信息一起传输。

       Chunked-Body   = *chunklast-chunktrailerCRLFchunk          = chunk-size [ chunk-extension ] CRLFchunk-data CRLFchunk-size     = 1*HEXlast-chunk     = 1*("0") [ chunk-extension ] CRLFchunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )chunk-ext-name = tokenchunk-ext-val  = token | quoted-stringchunk-data     = chunk-size(OCTET)trailer        = *(entity-header CRLF)

“chunk-size”用16进制字符串表明了分块的大小。分块编码以一个任意的大小为0的分块结束，随后以空行结尾。

分块的尾部允许发送者添加额外的HTTP头字段。尾部头字段部分表明了在分块的尾部包含了哪些消息头字段（14.40节）。

使用分块响应的服务端不能在尾部中包含任何的头字段，除非满足以下任一条件：

1. 请求中包含有指定了分块响应尾部是可接收的TE头字段。参见14.39节。
2. 服务端是响应的源服务端，尾部头字段全部由可选的元数据组成，且接收者在没有接收到这些元数据的时候也能使用这个响应消息（某种意义上是可接收的响应）。换句话说，源服务端接受在消息传输中丢失尾部字段的异常情况。、

这个需求阻止了当消息被HTTP/1.1的接收者接受时的发生的互操作性失败的可能，即便随后转发给了HTTP/1.0的接收者。它避免了这样一种情况，即遵守协议可能需要在代理上有一个可能无限的缓冲区。

在附录19.4.6中提供了一个处理分块体的案例。

所有HTTP/1.1的应用必须能够接受和解码分块传输，并且必须忽略未知的分块扩展部分。

3.7 媒体类型

为了提供开放的、可扩展的数据类型和类型转让，HTTP在Content-Type和Accept头字段中使用了网络媒体类型（Internet Media Types）。

       media-type     = type "/" subtype *( ";" parameter )type           = tokensubtype        = token

在属性/值中的"type/subtype"后面可能跟随有参数。

“type”、“subtype”和“parameter”属性名不区分大小写。“parameter”是否区分大小写取决于其名称的语法。在“type”和“subtype”之间不能有连续空格。“parameter”是否存在对于media-type的处理都应该是有意义的，取决于媒体类型注册表中的定义。

注意，旧HTTP应用不能识别媒体类型参数。当给旧HTTP应用发送数据时，应该只有当“type/subtype”需要参数时才使用参数。

media-type值在IANA中注册。在RFC 1590中描述了media-type的注册过程。不建议使用未注册的media-type。

3.7.1 规范及默认文本

互联网媒体类型（media-type）注册在一个规范表中。除了“文本”类型，所有通过HTTP消息传输的实体（entity-body）必须在它传输之前就应该在规范表中注册，就像下面这段话定义的一样。

在规范表中，“文本”类型的媒体子类型（media-subtype）使用CRLF作为文本的换行符。HTTP放宽了这一需求，当实体以文本类型完全一致地完成之后，HTTP允许使用单独的CR或者LF作为作为换行符。在通过HTTP接受的文本媒体中，HTTP应用必须能够接受CRLF、CR和LF作为文本类型的换行符。另外，如果文本是用没有使用13或者10个字节分别代表CR和LF的字符集表示的，如同多字节字符集一样，HTTP允许该字符集使用任意长度的字节序列来表示CR和LF作为换行符。这个关于换行符的灵活性只适用于实体中的文本媒体。单独的CR或者LF不能替换HTTP控制结构（头域和多部边界（multiparty boundaries））中的CRLF。

如果实体使用了内容编码（content-coding），底层数据在被编码之前必须使用上述的格式。

“charset”参数使用一些媒体类型来定义数据的字符集。当通过HTTP接收时，如果消息发送者没有明确地指定字符集数，“text”类型的媒体子类型被定义为拥有一个默认的字符集值“ISO-8859-1”。使用ISO-8859-1或其子集以外的字符集表示的数据必须用一个合适的字符集值来标识。兼容性问题参考3.4.1节.

3.7.2 多实体类型（Multipart Types）

MIME提供了若干个“multipart”类型 - - 在单个的消息体中封装了一个或者多个实体。所有的多实体类型分享一个通用的语法，如同在RFC 2046中定义的那样，同时必须包含一个边界参数作为媒体类型值的一部分。消息体本身就是一个协议元素，因此必须只能使用CRLF作为各个实体之间的换行符。不像在RFC 2046中描述的那样，任何多实体消息的结尾必须是空的；HTTP应用不能传输多实体结尾部分（尽管源多实体消息包含一个结尾）。存在这些限制是为了保持多实体消息体的自定界特性，其中消息体的“结束”由结束的多实体边界表示。

通常，HTTP对待多实体消息体（multipart message-body）与其它媒体类型没有分别：严格地称为有效载荷（strictly as payload）。一个例子就是在206（局部内容）响应中出现的“multipart/byteranges”类型（附录19.2），这个响应能够被一些使用HTTP缓存机制（在13.5.4和14.16节中有描述）的应用解析。除此之外，HTTP用户代理应该遵循与MIME用户代理在接收多实体类型时相同或类似的行为。多实体消息体中每个实体中的MIME头域在被MIME语法定义之前对于HTTP来说都是没有任何意义的。

通常，HTTP用户代理应该遵循与MIME用户代理在接收多实体类型时相同或类似的行为。如果应用接收到一个不能识别的多实体子类型，应用必须把它当作“multipart/mixed”类型等同对待。

注意：“multipart/form-data”类型已经被明确指定用于为POST请求传递表单数据。参考RFC 1867。

3.8 产品令牌（Product Tokens）

产品令牌被用来允许正在通信的应用使用软件名称和版本来标识它们自己。使用产品令牌的大多数域也允许用空格分隔的形式列出应用重要组成部分的子产品。按照惯例，被列出的产品以它们的重要性排序来标识应用。

       product         = token ["/" product-version]product-version = token

例如：

       User-Agent: CERN-LineMode/2.15 libwww/2.17b3Server: Apache/0.8.4

产品令牌应该简明扼要。它们不能为了打广告或者其它非必须的信息来使用。尽管product-version中可能出现任何的令牌字符，但这些字符应该只能用于版本标识符（例如，相同产品的连续版本应该只有product-version部分是不同的）。

3.9 权重（Quality Values）

HTTP内容协商(第12节)使用简短的“浮点数”表示各种可协商参数的相对重要性(“权重”)。权重被规范化为从0到1的真实的数字，0是最小值，1是最大值。如果一个参数的权重是0，那么对客户端来说，携带这个参数的内容是“不可接收的”。HTTP/1.1不能生成超过3位小数的权重值。用户配置的值应该也同样受这个限制。

       qvalue         = ( "0" [ "." 0*3DIGIT ] )| ( "1" [ "." 0*3("0") ] )

“Quality values”用词不当，因为这些值仅仅代表了期望值的关联下降。

3.10 语言标签（Language Tags）

语言标签标识了一种说、写或者其它用于人与人之间信息交流传递的自然语言。计算机语言被明确地包含其中。HTTP在Accept-Language和Content-Language字段中使用语言标签。

        language-tag  = primary-tag *( "-" subtag )primary-tag   = 1*8ALPHAsubtag        = 1*8ALPHA

标签中不允许出现空格，所有标签都是忽略大小写的。语言标签的命名空间由IANA进行管理。示例标签：

       en, en-US, en-cockney, i-cherokee, x-pig-latin

任何双字母主标签（例如：en）都是ISO-639语言的缩写，任何以双字母开头的子标签都是ISO-3166国家代码。（上示的最后3个标签是没有注册的标签；除了最后一个的所有其它标签都应该在未来被注册）。

3.11 实体标签（Entity Tags）

实体标签被用来比较来自于同一请求资源中的两个或者多个实体。HTTP/1.1在ETag（14.19节）、If-Match (14.24节)、If-None-Match (14.26节)和If-Range (14.27节)头字段中使用了实体标签。13.3.3节定义了它们是如何作为缓存验证器进行使用和比较的。实体标签由一个不透明的引用字符串组成，可能有一个弱指示器前缀。

      entity-tag = [ weak ] opaque-tagweak       = "W/"opaque-tag = quoted-string

只有当来自于同一个资源的两个实体的字节相等，它们才可能共享一个“强实体标签”。

“弱实体标签”，以“W/”前缀表示，只有当来自于同一个资源的两个实体相等并且在语法上没有重大改变、能互相替换时，它们才可能共享这个标签。弱实体标签只能同于弱比较。

跨越一个独特资源的所有实体的所有版本的实体标签必须是唯一的。一个给定的实体标签可能被用于不同URI请求的实体。在请求不同URI的实体中相同的实体标签不代表这些请求实体也是相等的。

3.12 范围单元（Range Units）

HTTP/1.1允许客户端请求响应中只包含部分实体的响应。 HTTP/1.1在Range（14.35节）和Content-Range（14.16节）头字段中使用范围单元。一个实体可以根据不同的结构单元分解为子单元。

      range-unit       = bytes-unit | other-range-unitbytes-unit       = "bytes"other-range-unit = token

HTTP/1.1中定义的唯一的范围单元就是“bytes”。HTTP/1.1的实现应用可能忽略使用其它单元指定的范围。

HTTP/1.1已经被设计为允许不依赖于范围知识的应用实现。

4. HTTP消息

4.1 消息类型

HTTP消息由客户端发送给服务端的请求以及服务端发送给客户端的响应组成。

       HTTP-message   = Request | Response     ; HTTP/1.1 messages

请求和响应使用RFC 822的通用消息格式来传输实体（消息负载）。这两种消息格式都由起始行、0或者头字段（headers）、一个表明头字段部分结束的空行（CRLF前什么也没有的行）和一个可能的消息体组成。

        generic-message = start-line*(message-header CRLF)CRLF[ message-body ]start-line      = Request-Line | Status-Line

为了健壮性，服务器应该忽略在期望是请求行（Request-Line）的地方接收到的空行。换句话说，如果服务端正在从消息的开始读取协议流，而又接收到了一个CRLF，那么就应该忽略这个CRLF。

某些有BUG的HTTP/1.0的客户端实现在POST请求之后生成了额外的CRLF。这里重申一下BNF明确禁止的内容：HTTP/1.1的客户端不能在请求之前或之后携带额外的CRLF。

4.2 消息头

HTTP请求头字段，包含了通用头、请求头、响应头和实体头，且都遵循RFC 822中3.1节给定的通用格式。每个头字段都由一个跟随冒号“：”的名称和字段值组成。字段名称是忽略大小写的。字段值前面可能出现多个连续空格，即使我们推荐使用单个空格。头字段可以通过在额外的行前面添加一个空格或者HT来扩展为多行。在生成HTTP结构时，应用应该遵循一个已知的或者指定的“普通格式”，因为可能存在一些应用不能够接收普通格式之前的任何东西。

       message-header = field-name ":" [ field-value ]field-name     = tokenfield-value    = *( field-content | LWS )field-content  = <the OCTETs making up the field-valueand consisting of either *TEXT or combinationsof token, separators, and quoted-string>

"field-context"字段不包含任何的前置或后置线性空格：在字段值第一个非空字符之前或最后一个非空字符之后出现的线性空格。这样的前置或后置LWS（线性空格）可能在不改变字段值语义的前提下被移除。出现在field-content之间的任何LWS在字段值被解释或转发到下游之前可能被一个SP（空格）替换。

接收到的含有不同名称头字段的顺序并不重要。不过，以首先发送通用头（general-header）字段，然后是请求头（request-header）或响应头（response-header）字段，最后以实体头字段结尾的方式是一个“好的实践”。

当且仅当头字段的所有字段值是以逗号分隔的列表定义的，那么消息中可能会出现字段名称相同的多重消息头（multiple-header）。必须提供一个将多重消息头结合为单个“字段名称：字段值”对的可能性，在不改变消息语义的前提下，依次将这些名称相同的字段的值添加到转换后的字段的头部，以逗号分隔。因此，接收到的相同名称字段的顺序在解释结合的字段值的时候就显得重要了，并且代理在转发消息时，不能改变这些字段的顺序。

4.3 消息体（message-body）

HTTP消息的消息体（如果有的话）是用来搬运跟请求或响应有关的实体（entity-body）的。只有当提供了传输编码 （transfer-coding），如同在头字段Transfer-Encoding中表明的那样，消息体才不同于实体。

       message-body = entity-body| <entity-body encoded as per Transfer-Encoding>

Transfer-Encoding字段必须用来指定应用程序应用的任何传输编码来确保消息安全和合理地传输。传输编码是消息而不是实体的一个属性，因此可能被请求或响应链中的任意的应用程序添加或者删除（然而，3.6节对某些被使用的传输编码有另外的限制）。

请求和响应对消息中何时使用消息体（message-body）有不同的规则。

请求中出现消息体的信号就是请求的消息头中包含了Content-Length或Transfer-Encoding头字段。如果请求方法的规范不允许在请求中发送实体，那么请求中就不能包含消息体。服务端应该读取和转发任何请求中的消息体；如果请求方法不包含实体的定义语义，那么在处理请求时应该忽略这个消息体。

对响应消息来说，消息中是否包含消息体取决于请求方法和响应状态码（6.1.1节）两个条件。HEAD请求方法的所有响应都不能包含消息体，尽管实体头字段的出现可能让人相信它们这样做了。所有1xx（报告的）、204（无内容）和304（未修改）的响应不能包含消息体。所有其它的响应都可以包含一个消息体，尽管它们的长度可能为0。

4.4 消息长度

消息的传输长度就是消息中出现的消息体的长度；也就是，在任何的传输编码被应用之后。当消息中包含了消息体，消息体的长度由以下条件（按出现顺序）决定：

1. 任何不能包含消息体的响应消息总是被头字段之后的第一个空行中断，不管消息中出现了怎样的实体头字段。
2. 如果出现了Transfer-Encoding头字段且字段值是“identity”以外的其它值，那么传输长度由“chunked”传输编码的使用决定，除非消息由于连接的关闭而中断。
3. 如果出现了Content-Length头字段，它的以八位字节代表的小数值即代表了实体长度也表示了传输长度。如果这两个长度是不同的，则Content-Length字段就不能发送。如果消息同时包含了Transfer-Encoding和Content-Length字段，则后者必须被忽略。
4. 如果消息使用了“multipart/byteranges”媒体类型，且没有另外指定传输长度，那么这个自定界媒体类型决定了传输长度。除非接收者能够解析这种媒体类型，否则发送者不能使用这种媒体类型；来自HTTP/1.1客户端并且携带有多字节范围指示器的范围头的请求的出现意味着这个客户端可以解析“multipart/byterangers”响应。

范围头可能由不懂 “multipart/byterangers”媒体类型的HTTP/1.0的代理转发；在这种情况下，服务端必须使用本章第1、3和5节定义的方法来分隔消息。

1. 服务端关闭了连接。（关闭连接不能表明请求体的结束，因为这样断绝了服务端发回响应的可能性。）

为了与HTTP/1.0兼容，包含消息体的HTTP/1.1的请求必须包含一个有效的Content-Length字段，除非服务端适用于HTTP/1.1。如果包含消息体的请求没有给定Content-Length字段，服务端不能决定消息的长度时应该响应400（请求错误），或者如果服务端坚持要接收一个有效的Content-Length字段的话，应该返回411（需求长度）。

所有接收到多个实体的HTTP/1.1的应用程序必须接受“chunked”传输编码，因此当消息长度不能确定时，优先对消息使用此机制。

消息不能同时包含Content-Length头字段和未标识的传输编码。如果消息包含未标识的传输编码，Content-Length必须被忽略。

有消息体的消息如果提供了Content-Length字段，它的字段值必须明确地满足消息体的8位字节的数量。当接收和检测到无效的长度时，HTTP/1.1的用户代理必须通知用户。

4.5 通用头字段（general-header fields）

存在一些普片适应请求和响应消息的头字段，但这些字段并不适应被转移的实体，它们只适应于被传输的消息。

       general-header = Cache-Control            ; Section 14.9| Connection               ; Section 14.10| Date                     ; Section 14.18| Pragma                   ; Section 14.32| Trailer                  ; Section 14.40| Transfer-Encoding        ; Section 14.41| Upgrade                  ; Section 14.42| Via                      ; Section 14.45| Warning                  ; Section 14.46

通用头字段只有在和协议版本的变化相结合时才能进行可靠地扩展。然而，如果新增的或者实验性质的头字段被通信中的所有部分都认为是通用头字段，那么它们可能被给定通用头字段的语义。不被识别的头字段被当作实体头字段。

5. 请求

客户端发送到服务端的请求的第一行包含：适应资源的请求方法、资源标识符和使用的协议版本。

        Request       = Request-Line              ; Section 5.1*(( general-header        ; Section 4.5| request-header         ; Section 5.3| entity-header ) CRLF)  ; Section 7.1CRLF[ message-body ]          ; Section 4.3

5.1 请求行

请求行以方法令牌（method token）开始，随后是请求的URI和协议版本，以CRLF结束。它们以SP（空格）字符作为分隔符。除了最后结尾的CRLF字符序列外，不允许额外的CR或LF字符出现。

        Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

5.1.1 方法

方法令牌表明了被请求URI标识的资源被处理的方法。方法是大小写敏感的。

       Method         = "OPTIONS"                ; Section 9.2| "GET"                    ; Section 9.3| "HEAD"                   ; Section 9.4| "POST"                   ; Section 9.5| "PUT"                    ; Section 9.6| "DELETE"                 ; Section 9.7| "TRACE"                  ; Section 9.8| "CONNECT"                ; Section 9.9| extension-methodextension-method = token

被资源允许的方法列表能够在“允许”头字段（14.7节）中指定。响应的返回码总是会通知客户端当前方法是否被资源允许，因为被允许的方法集能够动态地改变。源服务端如果能识别这种方法而该方法又不被资源所允许，则服务端应该响应405（Method Not Allowed）的状态码；如果服务端不能识别这种方法，又或者没有这种方法的实现，则服务端应该响应501（Not Implemented）的状态码。GET和HEAD方法必须被所有常用目标服务端所支持。所有其它的方法都是可选的；然而，如果以上的方法都被实现了，它们必须实现在第9章中指定的相同的语义。

5.1.2 请求URI

请求URI就是一个统一资源标识符（Uniform Resource Identifier），标识了适应请求的资源。

       Request-URI    = "*" | absoluteURI | abs_path | authority

请求URI的四个选项都依赖于请求的性质。“*”意味着请求并不适应某一特定的资源，只适应服务端自己，并且只有当请求的方法不必适应某一资源的时候才允许这样做。看起来就像下面这样：

       OPTIONS * HTTP/1.1

当请求被转发给代理的时候，一个绝对URI是必须的。代理就是转发请求或者从有效的缓存中返回响应的服务。注意，代理可能会将请求转发给另一个代理，或者直接转发到绝对URI指定的服务端。为了避免请求循环，代理必须能够识别所有它所属的服务端名称，包括别名、本地变量和IP地址。一个可能的请求行的案例如下：

       GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

为了在以后的HTTP版本的所有请求中传输绝对URI请求，所有HTTP/1.1的服务端必须能够接收绝对URI格式的请求，尽管HTTP/1.1的客户端只生成适应于代理的请求。

授权格式只在CONNECT请求方法中才能够使用。

最常用的请求URI的格式就是被用来标识服务端或者网关上的资源。在这种情况下，URI的绝对路径必须被当作请求URI来传输，同时URI的网络地址必须在Host头字段中被传输。例如，一个想要从源服务端里检索上述资源的客户端会建立一个在主机“www.w3.org”的80端口上的TCP连接，然后发送这些行：

       GET /pub/WWW/TheProject.html HTTP/1.1Host: www.w3.org

后面就是请求的剩余部分。注意，请求的绝对路径不能为空；如果原始URI就是空的，则必须给定一个“/”（服务端根路径）。

请求URI以3.2.1节中指定的格式进行传输。如果请求URI是用“% HEX HEX”编码进行编码的，源服务端为了对请求进行合适地解释必须对请求URI进行解码。服务端应该给无效的请求URI响应合适地状态码。

一个透明的代理在转发请求给下一个服务的时候，不能重写请求URI中的“abs_path”部分，除了以上提到的用“/”替换null路径。

注意：当源服务端为了保留的目的错误地使用了非保留的URI时，“不重写”规则阻止了代理改变请求的原意。实现者应该意识到HTTP/1.1之前的代理服务可能已经重写了请求URI。

5.2 请求标识的资源

网络请求标识的精确的资源是通过检查请求URI和Host头字段来决定的。

不允许资源因请求主机的不同而发生变化的源服务器在决定一个HTTP/1.1请求标识的资源的时候可能会忽略Host头字段的值。（但是可以参考19.6.1.1节中，有对HTTP/1.1对Host字段支持的另外的需求）

基于请求主机来区分资源的源服务器（有时根据虚拟主机或虚拟主机名称）必须使用以下规则来决定HTTP/1.1请求的请求资源：

1. 如果请求URI是绝对路径，则主机就是请求URI的一部分。任何Host头字段的值都必须被忽略；
2. 如果请求URI不是绝对路径，且请求包含Host头字段，则主机由Host头字段的值确定；
3. 如果被规则1或规则2确定的主机是无效的，则必须响应一个400（错误请求）状态码；

缺少Host头字段的HTTP/1.0的请求接收者可能会尝试使用启发法（例如，对特定的主机的一些唯一的内容进行的URI的检查）来精确地定位被请求的资源。

5.3 请求头字段

请求头字段允许客户端向服务器传输跟请求和客户端相关的额外的信息。这些字段扮演了请求标识符的角色，与编程语言的方法调用的参数有着相同的语义。

       request-header = Accept                   ; Section 14.1| Accept-Charset           ; Section 14.2| Accept-Encoding          ; Section 14.3| Accept-Language          ; Section 14.4| Authorization            ; Section 14.8| Expect                   ; Section 14.20| From                     ; Section 14.22| Host                     ; Section 14.23| If-Match                 ; Section 14.24| If-Modified-Since        ; Section 14.25| If-None-Match            ; Section 14.26| If-Range                 ; Section 14.27| If-Unmodified-Since      ; Section 14.28| Max-Forwards             ; Section 14.31| Proxy-Authorization      ; Section 14.34| Range                    ; Section 14.35| Referer                  ; Section 14.36| TE                       ; Section 14.39| User-Agent               ; Section 14.43

请求头字段只有在和协议版本的变化相结合时才能进行可靠地扩展。然而，如果新增的或者实验性质的头字段被通信中的所有部分都认为是请求头字段，那么它们可能被给定请求头字段的语义。不被识别的请求头字段被当作实体头字段。

6. 响应

在接收和解释请求消息后，服务器用HTTP响应消息进行响应。

       Response      = Status-Line               ; Section 6.1*(( general-header        ; Section 4.5| response-header        ; Section 6.2| entity-header ) CRLF)  ; Section 7.1CRLF[ message-body ]          ; Section 7.2

6.1 状态行

响应消息的第一行就是状态行，由协议版本以及随后的状态码和原文短语组成，每个元素由SP字符（空格）分割。除了最后结尾的CRLF字符序列外，不允许额外的CR或LF字符出现。

       Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

6.1.1 状态码（Status-Code）和原因短语（Reason-Phrase）

Status-Code是试图去理解和满足请求的三位整形数字的响应码。这些状态码全部都在第10章中定义。Reason-Phrase是打算给状态码给定一个简短的本意描述。Status-Code是给计算机用的，而Reason-Phrase是给人类用的。客户端不被要求去检查或者显示原因短语。

状态码的第一个数字定义了响应的类型。最后2个数字不扮演任何分类的角色。第一个数字有5个值：

• 1xx：情报 - 已接收到请求，正在处理
• 2xx：成功 - 行动已经被成功接收、理解和接受
• 3xx：转发 - 为了完成请求，必须采取进一步的行动
• 4xx：客户端错误 - 请求包含错误语法或不能实现
• 5xx：服务器错误 - 服务器不能完成一个明显的有效的请求

以下显示了HTTP/1.1定义的状态码的个体值和其对应的原因描述。这些原因描述全部都只是建议性的 – 它们可能在不影响协议的前提下被本地等同的短语所替换。

      Status-Code    ="100"  ; Section 10.1.1: Continue| "101"  ; Section 10.1.2: Switching Protocols| "200"  ; Section 10.2.1: OK| "201"  ; Section 10.2.2: Created| "202"  ; Section 10.2.3: Accepted| "203"  ; Section 10.2.4: Non-Authoritative Information| "204"  ; Section 10.2.5: No Content| "205"  ; Section 10.2.6: Reset Content| "206"  ; Section 10.2.7: Partial Content| "300"  ; Section 10.3.1: Multiple Choices| "301"  ; Section 10.3.2: Moved Permanently| "302"  ; Section 10.3.3: Found| "303"  ; Section 10.3.4: See Other| "304"  ; Section 10.3.5: Not Modified| "305"  ; Section 10.3.6: Use Proxy| "307"  ; Section 10.3.8: Temporary Redirect| "400"  ; Section 10.4.1: Bad Request| "401"  ; Section 10.4.2: Unauthorized| "402"  ; Section 10.4.3: Payment Required| "403"  ; Section 10.4.4: Forbidden| "404"  ; Section 10.4.5: Not Found| "405"  ; Section 10.4.6: Method Not Allowed| "406"  ; Section 10.4.7: Not Acceptable| "407"  ; Section 10.4.8: Proxy Authentication Required| "408"  ; Section 10.4.9: Request Time-out| "409"  ; Section 10.4.10: Conflict| "410"  ; Section 10.4.11: Gone| "411"  ; Section 10.4.12: Length Required| "412"  ; Section 10.4.13: Precondition Failed| "413"  ; Section 10.4.14: Request Entity Too Large| "414"  ; Section 10.4.15: Request-URI Too Large| "415"  ; Section 10.4.16: Unsupported Media Type| "416"  ; Section 10.4.17: Requested range not satisfiable| "417"  ; Section 10.4.18: Expectation Failed| "500"  ; Section 10.5.1: Internal Server Error| "501"  ; Section 10.5.2: Not Implemented| "502"  ; Section 10.5.3: Bad Gateway| "503"  ; Section 10.5.4: Service Unavailable| "504"  ; Section 10.5.5: Gateway Time-out| "505"  ; Section 10.5.6: HTTP Version not supported| extension-codeextension-code = 3DIGITReason-Phrase  = *<TEXT, excluding CR, LF>

HTTP状态码是可扩展的。HTTP的应用程序不要求去理解所有已注册的状态码的含义，尽管理解这些是明显值得的。然而，应用程序必须理解状态码所代表的类型，即状态码第一个数字的含义，同时，不能识别的状态码都要被当作该类型的x00状态码处理，且不能缓存未识别的响应。例如，客户端接收到了一个431的未识别的状态码，那么就可以被安全地假定为客户端请求存在一些问题，并将响应视为接收到了一个400状态码。在这种情况下，用户代理应该提供给用户返回响应的实体，因为实体中可能包含对这些不常用状态码的人类可读的信息描述。

6.2 响应头字段

响应头字段允许服务器传输状态行不能替换的有关响应的额外的信息。这些头字段给定了有关服务器或者更深一层地有关访问请求URI标识的资源的信息。

       response-header = Accept-Ranges           ; Section 14.5| Age                     ; Section 14.6| ETag                    ; Section 14.19| Location                ; Section 14.30| Proxy-Authenticate      ; Section 14.33| Retry-After             ; Section 14.37| Server                  ; Section 14.38| Vary                    ; Section 14.44| WWW-Authenticate        ; Section 14.47

响应头字段只有在和协议版本的变化相结合时才能进行可靠地扩展。然而，如果新增的或者实验性质的头字段被通信中的所有部分都认为是响应头字段，那么它们可能被给定响应头字段的语义。不被识别的响应头字段被当作实体头字段。

7. 实体

请求或响应如果没有请求方法或者响应状态码的限制的话可能会传输一个实体。实体由实体头字段和实体体（entity-body）组成，尽管一些响应只会包含实体头字段。

在本章中，发送者和接收者既可能是客户端也可能是服务端，依赖于谁发送实体，谁接收实体。

7.1 实体头字段

实体头字段定义了有关实体体的元数据信息，如果没有提供实体体，则是有关于请求标识的资源的信息。部分元信息是可选的，而有些对于本规范的部分内容来说又是必须的。

       entity-header  = Allow                    ; Section 14.7| Content-Encoding         ; Section 14.11| Content-Language         ; Section 14.12| Content-Length           ; Section 14.13| Content-Location         ; Section 14.14| Content-MD5              ; Section 14.15| Content-Range            ; Section 14.16| Content-Type             ; Section 14.17| Expires                  ; Section 14.21| Last-Modified            ; Section 14.29| extension-headerextension-header = message-header

“extension-header”头字段允许在不改变协议的前提下定义额外的实体头字段，但这些字段不能假定为是被接收者所识别的。不能识别的头字段应该被接收者忽略，同时必须被透明的代理转发。

7.2 实体体

HTTP请求和响应中的任何实体都是由实体头字段定义的格式和编码发送的。

       entity-body    = *OCTET

只有当提供了消息体的时候，消息中才能够提供实体，参考4.3节中的描述。实体是通过对确保消息安全和合适传输的传输编码（ Transfer-Encoding）进行解码而从消息体中获取的。

7.2.1 类型

当消息中包含实体的时候，实体的数据类型是通过Content-Type和Content-Encoding这两个头字段决定的。两者定义了一个双层的、有序的编码模型：

       entity-body := Content-Encoding( Content-Type( data ) )

Content-Type指定了潜在数据的媒体类型（media-type）。Content-Encoding可能被用来表明适用于数据的额外的内容编码，通常用于数据压缩的目的，这些编码是请求资源的一个属性。没有默认的编码。

任何包含实体的HTTP/1.1的消息都应该包含定义实体媒体类型的Content-Type头字段。只有当Content-Type头字段为空的时候（没有提供这个字段），消息接收者才可能假定通过检视实体内容和（或）标识资源的URI的扩展名来猜测实体的媒体类型。如果是未知的媒体类型，消息接受者应该当作“application/octet-stream”对待。

7.2.2 实体长度

消息的实体长度就是消息体在被任何传输编码应用之前的长度。4.4节定义了消息体是如何决定它的传输长度的。

8. 连接

8.1 持久化连接

8.1.1 目的

在持久化连接之前，对每一个URL都建立了一个独立的TCP连接，增加了HTTP服务器的负载，同时导致了网络拥塞。内联图片和其它相关数据的使用经常需要客户端向同一服务器在较短时间内发送多个请求。对这些性能问题和原型实现结果的分析是可用的^{17 18}。实现经验和对真实HTTP/1.1实现的测试展示了好的结果¹⁹。另一种选择已经探索过了，例如，T/TCP²⁰。

持久化HTTP连接有许多优点：

• 通过打开和关闭少量的TCP连接，路由器和主机（客户端、服务器、代理、网关、通道，或缓存系统）就节约了CPU时间，同时主机也节省了用于TCP协议控制块的内存。
• HTTP请求和响应能够在连接上形成一个管道。管道允许一个客户端可以不需要等待响应而发送多个请求，允许使用单个TCP连接是非常高效的，有着很低的时间消耗。
• 由于TCP持续连接导致的数据包的减少也会减少网络拥塞，同时给TCP充足的时间去决定网络拥塞的状态。
• 后续请求的潜在因数减少了，因为不会把时间花费在TCP握手连接上了。
• HTTP可以发展得更加地优雅，因为在错误被报告时，少去了关闭TCP连接的损耗。使用更高版本HTTP的客户端可以乐观地尝试新的特性，但是如果通信是建立在旧的服务器上的，在错误被报告以后，可以用旧的语法进行重试。

HTTP实现程序应该实现持久化连接。

8.1.2 概述

在HTTP/1.1和其之前版本的最大意义的不同就在于持久化连接是任何HTTP连接的默认行为。也就是说，除非另外指定，否则客户端应该假设服务器会保持持久化连接，即使服务器返回了错误响应之后。

持久化连接提供了一种机制，这种机制可以使客户端和服务器标记TCP连接的关闭。这个标记发生在连接头字段上。一旦某个关闭被标记了，客户端就不能在此连接上发送任何请求了。

8.1.2.1 协商

HTTP/1.1服务器可以假定HTTP/1.1客户端打算保持持久化连接，除非连接头包含请求发送过来的连接令牌“close”。如果服务器在发送响应之后选择立即关闭连接，那么它应该发送一个包含“close”连接令牌（connection-token）的连接头（Connection header）过去。

HTTP/1.1客户端会期望连接保持开启，但是是否保持开启依赖于服务器的响应中是否包含“close”连接令牌的连接头。一旦客户端在发送请求后不想再保持连接，它应该发送一个包含“close”连接令牌的连接头。

如果客户端或服务器发送了一个包含“close”连接令牌的连接头，则当前请求就是此连接的最后一个请求。

客户端和服务器不应该假设低于HTTP/1.1版本的应用会保持持久化连接除非有明确指定。参考19.6.2节了解更多关于HTTP/1.0客户端向下兼容的信息。

为了保持持久化连接，连接中的所有消息必须有一个自定义的长度（不是由于连接关闭而定义的），如4.4节所述。

8.1.2.2 管道

支持持久化连接的客户端会将请求“管道化”（发送多个不需要等待响应的请求）。服务器必须按照接收请求的顺序返回响应。

假定持久化连接并且在建立连接后立即管道化的客户端在第一次尝试管道化失败后应该准备重试连接。如果客户端做了这样的重试，在它知道连接是持久化之前不准管道化。如果服务器在发送所有对应的响应之前关闭了连接，客户端必须也要准备重新发送请求。

客户端不应该使用非幂等方法或非幂等方法的序列对请求管道化（参考9.1.2节）。否则，一个传输连接过早的中断能够导致不确定的结果。希望发送非幂等请求的客户端应该等待发送请求，除非它收到了上一个请求的响应码。

8.1.3 代理服务器

尤其重要的是代理服务器正确地实现了在14.10节中指定的连接头字段的属性。

代理服务器必须分别对其连接的客户端和源服务器（或其它的代理服务器）标记持久化连接。每个持久化连接只应用于一个传输连接。

代理服务器不准和HTTP/1.0的客户端建立HTTP/1.1的持久化连接（但是可以参考RFC 2068中许多HTTP/1.0客户端实现的Keep-Alive头问题的信息和讨论）。

8.1.4 实际考虑（Practical Considerations）

服务器都会设置一个超时时间，当超过超时时间后，它们就不会再保留非激活的连接了。代理服务器可能会设置一个比较高的值，因为有可能客户端会在同一个服务器上建立多个连接。持久化连接的使用对客户端或服务器的超时时间的长度（或超时时间的存在）没有要求。

设置了超时时间的客户端或服务器应该优雅地关闭连接。客户端和服务器两者都应该持续监控传输关闭的另一端，并且在合适的时候对其进行响应。如果客户端或服务器没有迅速地检测到另外一边的关闭，就能够导致网络资源不必要的耗尽。

客户端、服务器和代理可能在任何时候关闭传输连接。例如，一个客户端也许正在服务器决定关闭“闲置的”连接的同一时间发起一个新的请求。从服务器的角度来看，它正在关闭一个闲置的连接，但从客户端的角度来看，请求正在被处理。

这意味着客户端、服务器和代理必须能够从异步关闭事件中恢复。只要请求序列是幂等的（参见9.1.2节），客户端软件应该重启传输连接，并且在没有用户交互的情况下重新传输中断的请求序列。非幂等的方法或序列不准自动重试，尽管用户代理也许给人工操作提供了请求重试的选项。在语义上理解应用的用户代理的确认可以替换用户确认。如果请求的第二序列失败，则不应该重复自动重试。

如果有可能的话，服务器应该总是对每个连接都至少有一个响应。服务器不应该在响应的中途关闭连接，除非怀疑出现了网络或客户端故障。

使用持久化连接的客户端应该限制保留对给定服务器并立连接的数量。单个用户的客户端不应该对任何服务器或代理保留超过两个连接。代理应该对服务器或另外的代理最多保持2*N个连接，其中N是同时激活的用户数量。这些指导方针都是打算用来改善HTTP响应时间并避免出现网络拥塞的。

8.2 消息传输需求

8.2.1 持久化连接和流控制

HTTP/1.1服务器应该维持持久化连接并且使用TCP流控制机制来解决临时负载，而不是关闭连接期待客户端重试。后者使用的技术会加剧网络拥塞。

8.2.2 监视错误状态消息的连接

发送消息体的HTTP/1.1（或更高版本）的客户端在传输请求的时候应该监视连接中出现的错误状态。如果客户端监视到了错误状态，就应该立即终止传输消息体。如果消息体是用“chunked”编码（3.6节）发送的，0长度块和空尾部会过早地被用来标识消息的结束。如果Content-Length头领先于消息体，则客户端必须关闭连接。

8.2.3 100（继续）状态的使用

100（继续）状态码的目的在于允许发送带消息体消息的客户端决定在客户端发送消息体之前服务器是否愿意接收请求（基于请求头）。在某些情况下，如果服务器没有查看消息体就拒绝了消息，那么客户端发送消息就会显得不合适或效率极低。

HTTP/1.1客户端需求：

• 如果客户端在接收到100响应后才会发送消息体，那么它必须发送值为“100-continue”的Expect请求头。
• 如果客户端不打算发送消息体，那么它禁止发送值为“100-continue”的Expect请求头。

由于存在使用旧协议的应用，HTTP/1.1允许存在发送了“Expect:100-continue”的客户端不会接收417（期望失败）或100状态码这样模棱两可的情况。因此，当客户端将这个请求头字段发送给源服务器（可能通过代理）时，即使它从没见过100响应码，也不应该在发送请求体之前等待无限长的时间。

HTTP/1.1源服务器需求：

• 在接收到包含期望“100-continue”的Expect请求头字段的请求之后，源服务器必须要么响应100状态码同时继续读取输入流，要么响应一个最终的状态码。禁止源服务器在发送100响应码之前就开始等待请求体。如果源服务器用最终状态码进行了响应，那么它可能关闭传输连接或可能继续读取并抛弃请求的剩下部分。禁止源服务器在响应了最终状态码后仍然执行请求方法。
• 如果请求消息不包含期望“100-continue”的Expect请求头字段，则源服务器不应该响应100状态码，如果这样的消息来自于HTTP/1.0（或更低版本）的客户端，则禁止响应100状态码。这个规则有个例外：为了兼容RFC 2068，服务器可能将100响应发送给不包含期望“100-continue”的Expect请求头字段的HTTP/1.1的PUT或POST请求。这个例外的目的就是最小化与未声明等待100状态码时间有关的任意客户端处理延迟，只应用于HTTP/1.1的请求，不适用于其它任一版本。
• 如果源服务器已经收到相应请求的部分或全部请求体，那么它可能会省略100响应。
• 一旦请求体被接收和处理完毕，发送了100响应码的源服务器最终必须发送一个最后的状态码，除非它过早地中断了传输连接。
• 如果源服务器接收了一个不包含期望“100-continue”的Expect请求头字段的请求，而这个请求又包含了请求体，且服务器在读取传输连接中的整个请求体之前就响应了一个最终状态码，那么服务器不应该关闭连接直到它读取了整个请求，或者直到客户端关闭连接。否则，客户端可能会不可靠地接收响应消息。然而，本需求没有讨论保护服务器免受来自拒绝服务（ denial-of-service）或严重损坏的客户端实现的攻击。

HTTP/1.1代理需求：

• 如果代理接收到了一个包含“100-continue”期望值的Expect请求头字段的请求，同时代理要么知道下一跳服务器是用HTTP/1.1或更高版本编译的，或者不知道下一跳服务器的HTTP的版本，都必须转发请求，包含Expect头字段。
• 如果代理知道服务器的版本是HTTP/1.0或者更低，则禁止转发这个请求，同时必须响应417（Expectation Failed）状态码。
• 代理服务器应当维护一个缓存，以记录最近访问下一站点服务器的HTTP版本号。
• 如果代理接收到的请求来自HTTP/1.0或更低版本的客户端，并且请求消息不包含“100-continue”期望值的Expect请求头字段，则禁止转发100响应。这点需求重写了在转发1xx响应时的一般规则（参考10.1节）。

8.2.4 服务器过早关闭连接时的客户端行为

如果HTTP/1.1客户端发送了一个包含请求体的请求，但是并不包含“100-continue”期望值的Expect请求头字段，同时如果客户端不是直接连接到源服务器，且如果客户端在接收到服务器任何响应之前就发现连接已经关闭了，则客户端应该重试请求。如果客户端进行了重试，就可以使用以下的“二进制指数补偿”算法来确保获取一个可靠的响应：

1. 初始化一个到服务器的新连接；
2. 发送请求头；
3. 将变量R初始化为到服务器的估计往返时间(例如，基于建立连接所需的时间)，或者初始化为常数5秒(如果往返时间不可用)；
4. 计算 T = R * ( 2 * * N)，其中N是本次请求之前重试的次数；
5. 要么等待来自服务器的错误消息，要么等待T秒（随便哪一个先到）；
6. 如果没有收到错误响应，等待T秒后就发送请求的请求体；
7. 如果客户端发现连接过早地关闭了，则从第一步开始重试，直到请求被接受，接收到错误响应，或者用户焦躁地中止重试处理。

如果在任何时候都收到错误响应，如果还没有发送完请求消息，则客户端不应该再继续下去了，应该关闭连接。