HTTP 语义

“http” URI 方案在此被定义，用于在由潜在 HTTP 源服务器在给定端口上监听 TCP（[TCP]）连接所管理的层级命名空间内铸造标识符。

  http-URI = "http" "://" authority path-abempty [ "?" query ]

“http” URI 的源服务器由 authority 组件标识，该组件包括主机标识符（[URI], 第 3.2.2 节） 和可选端口号（[URI], 第 3.2.3 节）。如果端口子组件为空或未给出，默认使用 TCP 端口 80（WWW 服务的保留端口）。源决定谁有权对标识的资源作出权威性响应，如 第 4.3.2 节 所定义。

发送者不得生成带有空主机标识符的 "http" URI。处理此类 URI 引用的接收者必须将其视为无效并拒绝。

层级路径组件和可选查询组件在该源的命名空间内标识目标资源。

“https” URI 方案在此被定义，用于在由潜在源服务器在给定端口上监听 TCP 连接并能够建立用于 HTTP 通信的 TLS（[TLS13]）连接并对其进行保护的层级命名空间内铸造标识符。在此上下文中，“已保护”特指服务器已被认证为代表所标识的 authority 行事，并且与该服务器的所有 HTTP 通信都具有对客户端和服务器均可接受的机密性和完整性保护。

  https-URI = "https" "://" authority path-abempty [ "?" query ]

“https” URI 的源服务器由 authority 组件标识，该组件包括主机标识符（[URI], 第 3.2.2 节） 和可选端口号（[URI], 第 3.2.3 节）。如果端口子组件为空或未给出，默认使用 TCP 端口 443（用于通过 TLS 的 HTTP 的保留端口）。源决定谁有权对标识的资源作出权威性响应，如 第 4.3.3 节 所定义。

发送者不得生成带有空主机标识符的 "https" URI。处理此类 URI 引用的接收者必须将其视为无效并拒绝。

层级路径组件和可选查询组件在该源的命名空间内标识目标资源。

客户端在将其对 “https” 资源的 HTTP 请求传输之前，必须确保这些请求是已被保护的，并且仅接受对这些请求的受保护响应。请注意，什么样的加密机制对客户端和服务器是可接受的通常是协商决定的，并可能随时间变化。

通过 “https” 方案提供的资源与 “http” 方案没有共享身份。它们是具有独立命名空间的不同来源。然而，定义为适用于同一主机的所有来源的 HTTP 扩展（例如 Cookie 协议 [COOKIE]）允许由一个服务设置的信息影响与匹配主机域组内其他服务的通信。这样的扩展应谨慎设计，以防止从受保护连接获得的信息被无意地在不安全的上下文中交换。

带有 "http" 或 "https" 方案的 URI 按照 第 6 节 中定义的方法进行规范化和比较，使用上述为每个方案描述的默认值。

HTTP 不要求使用特定的方法来确定等价性。例如，缓存键可在语法级规范化之后作为简单字符串进行比较，或在基于方案的规范化之后进行比较。

• 如果端口等于某方案的默认端口，则正常形式是省略端口子组件。
• 当不被用作 OPTIONS 请求的目标时，空路径组件等同于绝对路径 “/”，因此正常形式是提供路径 “/”。
• 方案和主机不区分大小写，通常以小写提供；所有其他组件以区分大小写的方式比较。
• 除“reserved”集合中的字符外，其他字符等价于它们的百分号编码八位组：正常形式是不对它们进行编码（参见 第 2.1 节 和 第 2.2 节）。

   http://example.com:80/~smith/home.html
   http://EXAMPLE.com/%7Esmith/home.html
   http://EXAMPLE.com:/%7esmith/home.html

两个在规范化后等价的 HTTP URI（使用任何方法）可以被认为标识相同的资源，任何 HTTP 组件可以执行规范化。因此，不应使用在规范化后等价的 HTTP URI 来标识不同的资源（参见 第 6.2 节）。

URI 通用语法中的 authority 也包括 userinfo 子组件（[URI], 第 3.2.1 节）用于在 URI 中包含用户认证信息。在该子组件中，使用 "user:password" 格式已被弃用。

一些实现利用 userinfo 组件用于认证信息的内部配置，例如命令调用选项、配置文件或书签列表中，即使这样的使用可能会暴露用户标识或密码。

当在消息中生成作为目标 URI 或字段值的 "http" 或 "https" URI 引用时，发送者不得生成 userinfo 子组件（及其 "@" 分隔符）。

在使用来自不受信任来源的 "http" 或 "https" URI 引用之前，接收者应解析 userinfo 并将其存在视为错误；它很可能被用于掩盖 authority 以实施网络钓鱼攻击。

片段标识符允许对次级资源进行间接识别，这与 URI 方案无关，如 第 3.5 节 所定义的一样。某些引用 URI 的协议元素允许包含片段，而其他协议元素则不允许。它们通过使用允许包含片段的元素的 ABNF 规则来区分；否则，使用排除片段的特定规则。

给定 URI 的 origin 是在将方案和主机规范化为小写并将端口规范化以去除任何前导零之后的三元组（scheme, host, port）。如果 URI 中省略了端口，则使用该方案的默认端口。例如，URI

   https://Example.Com/happy.js

将具有起源

   { "https", "example.com", "443" }

   https://example.com:443

每个 origin 定义其自己的命名空间并控制该命名空间内标识符如何映射到资源。反过来，origin 对有效请求的响应方式在时间上的一致性决定了用户将与 URI 关联的语义，而这些语义的有用性最终将使这些机制成为用户未来引用和访问的资源。

如果两个 origin 在方案、主机或端口上存在差异，则它们是不同的。即使可以验证同一实体控制两个不同的 origin，除非源权威服务器显式地为其别名，否则这两个 origin 下的命名空间仍然是不同的。

Origin 也在 HTML 及相关的 Web 协议中使用，超出本文档的范围，如 [RFC6454] 所述。

虽然 HTTP 与传输协议无关，但 “http” 方案（第 4.2.1 节）特指将 authority 与在所指示端口上为所识别主机监听 TCP 连接的 origin 服务器的控制权相关联。这是一种非常弱的权威感，因为它依赖于客户端特定的名称解析机制以及可能未被路径上攻击者保护的通信。不过，在受信任的环境中，它足以将 "http" 标识符绑定到 origin 服务器以实现一致解析。

如果主机标识符以 IP 地址提供，则 origin 服务器是该 IP 地址上在所指示 TCP 端口监听的主机（如果存在）。如果主机是注册名称，则该注册名称是与名称解析服务（例如 DNS）一起使用的间接标识符，以查找适当的 origin 服务器的地址。

当在要求访问所指示资源的上下文中使用 "http" URI 时，客户端可以尝试通过将主机标识符解析为 IP 地址、在所指示端口向该地址建立 TCP 连接，并在该连接上发送包含与客户端目标 URI 匹配的请求目标的 HTTP 请求消息来访问该资源（第 7.1 节）。

如果服务器对该请求以非临时的 HTTP 响应消息作出响应（如 第 15 节 所述），则该响应被视为对客户端请求的权威性答复。

注意，以上并不是获得权威性响应的唯一手段，也不意味着始终需要权威性响应（参见 [CACHING]）。例如，Alt-Svc 头字段（[ALTSVC]）允许 origin 服务器标识对该 origin 也具有权威性的其他服务。对由 "http" 标识的资源的访问也可能由本文档范围之外的协议提供。

“https” 方案（第 4.2.2 节）基于服务器能够使用与客户端认为对所标识的 origin 服务器可信的证书相对应的私钥来确定权威性。客户端通常依赖于从某个预先安排或配置的信任锚传递来的信任链来认定证书是可信的（参见 第 4.3.4 节）。

在 HTTP/1.1 及更早版本中，只有当客户端与该 URI origin 的主机在已成功建立并受保护的连接上通信时，才会将权威性归属于服务器。连接建立和证书验证被用作权威性的证明。

在 HTTP/2 和 HTTP/3 中，当客户端在已成功建立并受保护的连接上通信，且 URI origin 的主机与服务器证书中出现的任一主机匹配并且客户端认为它可以为该 URI 向该主机打开连接时，客户端会将权威性归属于服务器。实际上，客户端将执行 DNS 查询以检查 origin 的主机是否与已建立连接的服务器 IP 地址相同。源服务器通过发送等效的 ORIGIN 帧可以移除此限制（参见 [RFC8336]）。

请求目标的主机和端口值在每个 HTTP 请求中传递，用以识别 origin 并将其与可能由同一服务器控制的其他命名空间区分开（第 7.2 节）。origin 有责任确保任何被授予其证书私钥控制权的服务同样负责管理相应的 “https” 命名空间，或至少准备拒绝看起来被错误定向的请求（参见 第 7.4 节）。

即使 origin 有权处理某些目标 URI 的请求，origin 服务器也可能不愿意处理这些请求。例如，当某主机在不同端口（例如 443 和 8000）上运行不同服务时，需要在 origin 服务器处检查目标 URI（即使连接已被保护），因为网络攻击者可能导致某个端口的连接被路由到另一个端口。未检查目标 URI 可能允许攻击者用另一个端口的看似权威的响应（例如 "https://example.com:8000/foo"）替换对某一目标 URI（例如 "https://example.com/foo"）的响应。

注意，“https” 方案不依赖于 TCP 和已连接的端口号来关联权威性，因为两者都在受保护通信之外，因此不能被信任为决定性的。因此，HTTP 通信可能通过任何被定义为已保护的通道进行（见 第 4.2.2 节），包括不使用 TCP 的协议。

当在要求访问所指示资源的上下文中使用 "https" URI 时，客户端可以通过将主机标识符解析为 IP 地址、在所指示端口向该地址建立 TCP 连接、在该 TCP 上成功启动 TLS 并在端到端上对连接进行保密性和完整性保护，然后在该连接上发送包含与客户端目标 URI 匹配的请求目标的 HTTP 请求消息来尝试访问该资源（第 7.1 节）。

如果服务器对该请求以非临时的 HTTP 响应消息作出响应（如 第 15 节 所述），则该响应被视为对客户端请求的权威性答复。

注意，以上并不是获得权威性响应的唯一手段，也不意味着始终需要权威性响应（参见 [CACHING]）。

为建立用于解引用 URI 的受保护连接，客户端必须验证服务的身份与 URI 的 origin 服务器相符且可接受。证书验证用于防止路径上攻击者或控制名称解析的攻击者冒充服务器。该过程要求客户端配置一组信任锚。

一般情况下，客户端必须使用 第 6 节 中定义的验证过程来验证服务身份（参见 [RFC6125]）。客户端必须从服务的主机构造一个参考标识：如果主机是字面 IP 地址（参见 第 4.3.5 节），参考标识为 IP-ID，否则主机为名称且参考标识为 DNS-ID。

客户端不得使用 CN-ID 类型的参考标识。如在 第 6.2.1 节 中所述，较旧的客户端可能会使用 CN-ID 类型的参考标识。

客户端可能被专门配置为接受替代形式的服务器身份验证。例如，客户端可能连接到地址和主机名动态变化的服务器，期望该服务出示特定证书（或匹配某个外部定义参考标识的证书），而不是与目标 URI 的 origin 匹配的证书。

在特殊情况下，客户端仅忽略服务器身份可能是合适的，但必须理解这会使连接暴露于主动攻击。

如果证书对于目标 URI 的 origin 无效，用户代理必须在继续之前从用户处获得确认（见 第 3.5 节）或以错误证书错误终止连接。自动化客户端必须将该错误记录到适当的审计日志（如可用）并且应终止连接（以错误证书错误）。自动化客户端可以提供一个配置项以禁用此检查，但必须提供一个启用该检查的设置。

在 "https" URI 的 "host" 字段中使用 IP 地址字面量标识的服务器具有类型为 IP-ID 的参考标识。IPv4 地址使用 "IPv4address" ABNF 规则，IPv6 地址使用带有 "IPv6address" 选项的 "IP-literal" 产生式；见 第 3.2.2 节。IP-ID 类型的参考标识包含 IP 地址的解码字节。

IPv4 地址为 4 个八位组，IPv6 地址为 16 个八位组。IP-ID 的使用未为其他 IP 版本定义。证书 subjectAltName 扩展中的 iPAddress 选项并未显式包含 IP 版本，因此依赖地址长度来区分版本；见 第 4.2.1.6 节。

类型为 IP-ID 的参考标识在地址与证书的 subjectAltName 扩展中的 iPAddress 值完全相同时匹配。

对 [RFC5234] 的 ABNF 规则的 #rule 扩展用于在某些基于列表的字段值定义中提高可读性。

构造符 "#" 的定义类似于 "*"，用于定义以逗号分隔的元素列表。完整形式为 "<n>#<m>element"，表示至少 <n> 且至多 <m> 个元素，每个元素由单个逗号 (",") 及可选空白（OWS，定义见 第 5.6.3 节）分隔。

Tokens 是不包含空白或分隔符的简短文本标识符。

  token          = 1*tchar

  tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
                 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
                 / DIGIT / ALPHA
                 ; any VCHAR, except delimiters

许多 HTTP 字段值使用通用语法组件定义，这些组件由空白或特定的分隔字符分隔。分隔符从不可用作 token 的 US-ASCII 可见字符集中选择（DQUOTE 及 "(),/:;<=>?@[\]{}"）。

本规范使用三条规则来表示线性空白的使用：OWS（可选空白）、RWS（必需空白）和 BWS（“不良”空白）。

OWS 规则用于可能出现零个或多个线性空白八位组的地方。对于偏好可选空白以提高可读性的协议元素，发送者应生成单个 SP 作为可选空白；否则，发送者不应生成可选空白，除非在就地消息过滤过程中需要覆盖无效或不需要的协议元素。

RWS 规则用于需要至少一个线性空白八位组以分隔字段标记的情况。发送者应将 RWS 生成为单个 SP。

OWS 和 RWS 在语义上等同于单个 SP。任何已知定义为 OWS 或 RWS 的内容在解释或向下游转发报文之前可以用单个 SP 替换。

BWS 规则用于语法仅出于历史原因允许可选空白的地方。发送者不得在报文中生成 BWS。接收方必须解析此类不良空白并在解释协议元素之前将其移除。

BWS 没有语义。任何已知定义为 BWS 的内容在解释或向下游转发报文之前可以被移除。

  OWS            = *( SP / HTAB )
                 ; optional whitespace
  RWS            = 1*( SP / HTAB )
                 ; required whitespace
  BWS            = OWS
                 ; "bad" whitespace

如果使用双引号将文本字符串括起，该字符串会被解析为单个值。

  quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
  qdtext         = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text

反斜杠八位组 ("\") 可作为 quoted-string 和注释构造中的单八位组引用机制。处理 quoted-string 值的接收方必须将 quoted-pair 视为被反斜杠后面的八位组所替代。

  quoted-pair    = "\" ( HTAB / SP / VCHAR / obs-text )

发送者除非必要（用于引用出现在字符串中的 DQUOTE 和反斜杠八位组），否则不应在 quoted-string 中生成 quoted-pair。发送者除非必要（用于引用注释中出现的括号 ["(" 和 ")"] 以及反斜杠八位组），否则不应在注释中生成 quoted-pair。

在某些 HTTP 字段中可以通过用圆括号将注释文本括起来来包含注释。注释仅允许出现在字段值定义中包含 "comment" 的字段中。

  comment        = "(" *( ctext / quoted-pair / comment ) ")"
  ctext          = HTAB / SP / %x21-27 / %x2A-5B / %x5D-7E / obs-text

参数是名称/值 对的实例；它们常用于字段值中，作为附加辅助信息到某个项的通用语法。每个参数通常由前置分号立即分隔。

  parameters      = *( OWS ";" OWS [ parameter ] )
  parameter       = parameter-name "=" parameter-value
  parameter-name  = token
  parameter-value = ( token / quoted-string )

参数名称不区分大小写。参数值可能区分或不区分大小写，取决于参数名称的语义。参数示例及一些等效形式可见于媒体类型（见 第 8.3.1 节）和 Accept 头字段（见 第 12.5.1 节）。

匹配 token 产生式的参数值可以作为 token 或在 quoted-string 中传输。引用和值未引用的值是等价的。

在 1995 年之前，服务器用于传达时间戳的三种不同格式被广泛使用。为兼容旧实现，这三种格式都在此定义。首选格式是互联网信息报文格式所使用的日期和时间规范的定长且单时区的子集（参见 [RFC5322]）。

  HTTP-date    = IMF-fixdate / obs-date

首选格式的一个示例是

Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate

两种过时格式的示例如下

Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format

解析 HTTP 字段中时间戳值的接收方必须接受所有三种 HTTP-date 格式。当发送者生成包含一个或多个定义为 HTTP-date 的时间戳的字段时，发送者必须以 IMF-fixdate 格式生成这些时间戳。

HTTP-date 值表示为协调世界时（UTC）的一个时刻实例。前两种格式通过三字母缩写 "GMT" 来指示 UTC；asctime 格式的值假定为 UTC。

时钟 是能够提供当前 UTC 时刻的合理近似的实现。时钟实现应使用 NTP（参见 [RFC5905]）或类似协议与 UTC 同步。

  IMF-fixdate  = day-name "," SP date1 SP time-of-day SP GMT
  ; fixed length/zone/capitalization subset of the format
  ; see Section 3.3 of [RFC5322]

  day-name     = %s"Mon" / %s"Tue" / %s"Wed"
               / %s"Thu" / %s"Fri" / %s"Sat" / %s"Sun"

  date1        = day SP month SP year
               ; e.g., 02 Jun 1982

  day          = 2DIGIT
  month        = %s"Jan" / %s"Feb" / %s"Mar" / %s"Apr"
               / %s"May" / %s"Jun" / %s"Jul" / %s"Aug"
               / %s"Sep" / %s"Oct" / %s"Nov" / %s"Dec"
  year         = 4DIGIT

  GMT          = %s"GMT"

  time-of-day  = hour ":" minute ":" second
               ; 00:00:00 - 23:59:60 (leap second)

  hour         = 2DIGIT
  minute       = 2DIGIT
  second       = 2DIGIT

  obs-date     = rfc850-date / asctime-date

  rfc850-date  = day-name-l "," SP date2 SP time-of-day SP GMT
  date2        = day "-" month "-" 2DIGIT
               ; e.g., 02-Jun-82

  day-name-l   = %s"Monday" / %s"Tuesday" / %s"Wednesday"
               / %s"Thursday" / %s"Friday" / %s"Saturday"
               / %s"Sunday"

  asctime-date = day-name SP date3 SP time-of-day SP year
  date3        = month SP ( 2DIGIT / ( SP 1DIGIT ))
               ; e.g., Jun  2

HTTP-date 区分大小写。注意，第 4.2 节 对缓存接收方放宽了这一点（参见 [CACHING]）。

发送者不得在 HTTP-date 中生成文法之外的额外空白。day-name、day、month、year 和 time-of-day 的语义与 Internet Message Format 中相应名称的构造定义相同（参见 [RFC5322] 的 第 3.3 节）。

接收 rfc850-date 格式时间戳值的接收方（该格式使用两位数年份）必须将看起来比当前时间晚超过 50 年的时间戳解释为最近的过去年份中具有相同后两位数字的年份。

除非字段定义另有约束，接收时间戳值的接收方应在解析时间戳时保持健壮。例如，报文有时会从非 HTTP 源通过 HTTP 转发，该源可能会生成 Internet Message Format 定义的任意日期和时间格式。

请求中内容的目的由方法语义定义（见 第 9 节）。

例如，PUT 请求内容中的表示（见 第 9.3.4 节）表示在请求成功应用后 目标资源 的期望状态，而 POST 请求内容中的表示（见 第 9.3.3 节）表示要由目标资源处理的信息。

在响应中，内容的目的由请求方法、响应状态码（见 第 15 节）以及描述该内容的响应字段来定义。例如，对 GET（见 第 9.3.1 节） 的 200 (OK) 响应的内容表示在报文发生时刻（见 第 6.6.1 节）观察到的 目标资源 的当前状态，而在对 POST 的响应中相同状态码的内容可能表示处理结果或应用处理后目标资源的新状态。

对 GET 的 206 (Partial Content) 响应的内容包含所选表示的单个部分或包含该表示多个部分的多部分消息体，如 第 15.3.7 节 所述。

带有错误状态码的响应消息通常包含表示错误条件的内容，使得内容描述错误状态以及建议的解决步骤。

对 HEAD 请求方法（见 第 9.3.2 节）的响应从不包含内容；相关的响应头字段仅指示若方法为 GET（见 第 9.3.1 节）时其值会是什么。

对 CONNECT 请求方法的 2xx (Successful) 响应会将连接切换为隧道模式，而不是包含内容（见 第 9.3.6 节）。

所有 1xx (Informational)、204 (No Content) 和 304 (Not Modified) 响应均不包含内容。

所有其他响应都包含内容，尽管该内容可能长度为零。

当完整或部分表示作为报文内容被传输时，发送方提供或接收方确定与该特定表示对应的资源标识符通常是可取的。例如，请求某资源的客户端可能希望获得特定于返回内容的标识符（例如“20210720T1711 时 Laguna Beach 的天气报告”）。对于来自预期随时间变化表示的资源的内容，这对共享或收藏链接很有用。

• 如果请求含有 Content-Location 头字段，则发送方断言该内容是由 Content-Location 字段值标识的资源的一个表示。然而，除非可以通过其他手段（本规范未定义）验证，否则该断言无法被信任。该信息仍可能对修订历史链接有用。
• 否则，HTTP 对该内容不提供标识，但更具体的标识符可能在内容本身中提供。

1. 如果请求方法是 HEAD 或响应状态码是 204 (No Content) 或 304 (Not Modified)，则响应中无内容。
2. 如果请求方法是 GET 且响应状态码是 200 (OK)，则内容是 目标资源 的一个表示（见 第 7.1 节）。
3. 如果请求方法是 GET 且响应状态码是 203 (Non-Authoritative Information)，则内容是由中间件提供的可能被修改或增强的 目标资源 的表示。
4. 如果请求方法是 GET 且响应状态码是 206 (Partial Content)，则内容是目标资源表示的一个或多个部分。
5. 如果响应具有 Content-Location 头字段且其字段值引用与目标 URI 相同的 URI，则内容是目标资源的一个表示。
6. 如果响应具有 Content-Location 头字段且其字段值引用与目标 URI 不同的 URI，则发送方断言该内容是由 Content-Location 字段值标识的资源的一个表示。然而，除非可以通过其他手段验证，否则该断言无法被信任。
7. 否则，HTTP 对该内容不提供标识，但更具体的标识符可能在内容本身中提供。

仅当所使用的 HTTP 版本支持且由显式分帧机制启用时，才可能存在尾部部分。例如，HTTP/1.1 的分块传输编码允许在内容之后发送尾部部分（参见 第 7.1.2 节）。

许多字段无法在头部部分之外处理，因为它们的评估在接收内容之前就是必要的，例如那些描述报文分帧、路由、认证、请求修饰、响应控制或内容格式的字段。发送方 MUST NOT 生成尾字段，除非发送方知道相应头字段名称的定义允许该字段在尾部中发送。

尾字段对于将报文从一个协议版本转发到另一个版本的中间件来说可能难以处理。如果整个报文可以在传输途中缓冲，某些中间件可以在转发之前将尾字段合并到头部部分（如适当）。然而在大多数情况下，尾字段只是被丢弃。接收方 MUST NOT 将尾字段合并到头部部分，除非接收方理解相应头字段的定义并且该定义明确允许且定义了如何安全地合并尾字段值。

在请求的 TE 头字段（见 第 10.1.4 节）中出现关键字 "trailers" 表明客户端愿意接受尾字段，代表其自身和任何下游客户端。对于来自中间件的请求，这意味着所有下游客户端都愿意在转发的响应中接受尾字段。注意，出现 "trailers" 并不意味着客户端（们）会处理响应中的任何特定尾字段；仅表示尾部部分不会被任何客户端丢弃。

由于尾字段在传输中可能被丢弃，服务器 SHOULD NOT 生成它认为用户代理必须接收的尾字段。

“Trailer” 头字段（见 第 6.6.2 节）可以被发送以指示可能在尾部部分发送的字段名，这允许接收方在处理内容之前为接收这些指示的元数据做准备。例如，如果某个字段名表明在接收内容时应动态计算校验和并在收到尾字段值后立即检查，这会很有用。

与头字段类似，具有相同名称的尾字段按接收顺序处理；多个同名尾字段行的语义等同于将多个值作为成员列表追加。可能在一条消息中被多次生成的尾字段 MUST 被定义为基于列表的字段，即使每个成员值仅在接收到每个字段行时处理一次。

在报文结束时，接收方 MAY 将接收到的一组尾字段视为一个与头字段类似但独立的 name/value 对数据结构。针对打算在尾部使用的字段，其字段规范中可以定义额外的处理期望（如果有的话）。

“Date” 头字段表示报文的起始日期和时间，具有与 Internet Message Format 中定义的 Origination Date Field (orig-date) 相同的语义。字段值为 HTTP-date，定义见 第 5.6.7 节。

  Date = HTTP-date

一个示例如下

Date: Tue, 15 Nov 1994 08:12:31 GMT

生成 Date 头字段的发送方 SHOULD 生成其字段值作为报文生成时间的最佳可用近似。理论上，该日期应表示在生成报文内容之前的那一刻。实际上，发送方可以在报文生成的任何时刻生成该日期值。

具有时钟的源服务器（参见 第 5.6.7 节）MUST 在所有 2xx (Successful)、3xx (Redirection) 和 4xx (Client Error) 响应中生成 Date 头字段，并且 MAY 在 1xx (Informational) 和 5xx (Server Error) 响应中生成 Date 头字段。

没有时钟的源服务器 MUST NOT 生成 Date 头字段。

具有时钟的接收方在收到没有 Date 头字段的响应报文时，MUST 记录其接收时间，并在将该报文缓存或转发下游时向报文头部追加相应的 Date 头字段。

具有时钟的接收方在收到带有无效 Date 头字段值的响应时 MAY 用响应的接收时间替换该值。

用户代理 MAY 在请求中发送 Date 头字段，尽管通常不会这样做，除非认为它向服务器传达的信息是有用的。例如，HTTP 的定制应用可能在用户代理与服务器的时钟存在差异时期望服务器基于该差异调整对用户请求的解释，因此会传送 Date。

“Trailer” 头字段提供发送方预计将在该报文的尾部部分发送的字段名列表。这允许接收方在开始处理内容之前为接收指示的元数据做准备。

  Trailer = #field-name

例如，发送方可以指示在内容流传输时会计算签名，并在尾字段中提供最终签名值。这允许接收方在接收内容的同时进行相同的校验。

打算在报文中生成一个或多个尾字段的发送方 SHOULD 在该报文的头部部分生成 Trailer 头字段，以指示哪些字段可能出现在尾部。

如果中间件在传输过程中丢弃了尾部部分，Trailer 字段可以提示哪些元数据丢失，尽管不能保证 Trailer 的发送方总是会发送所命名的字段。

如果客户端具有缓存 [CACHING] 且请求可以由其满足，则通常会先将请求定向到缓存。

如果请求不能由缓存满足，典型客户端会检查其配置以确定是否应使用代理来满足该请求。代理配置依实现而异，但通常基于 URI 前缀匹配、选择性 authority 匹配或两者兼有，并且代理自身通常由 "http" 或 "https" URI 标识。

如果适用 "http" 或 "https" 代理，客户端通过建立（或重用）到该代理的入站连接，然后向其发送一个包含与客户端 target URI 匹配的 request target 的 HTTP 请求报文来进行连接。

如果没有适用的代理，典型客户端将调用一个处理例程（针对目标 URI 的 scheme 特定）以获取对已识别资源的访问。如何实现取决于目标 URI 的 scheme，并由其关联规范定义。

第 4.3.2 节 定义了如何通过建立（或重用）到所识别 origin 的入站连接并向其发送包含与客户端 target URI 匹配的 request target 的 HTTP 请求报文来获取对 "http" 资源的访问。

第 4.3.3 节 定义了如何通过建立（或重用）到对所识别 origin 具有权威性的 origin 服务器的受保护连接，并向其发送包含与客户端 target URI 匹配的 request target 的 HTTP 请求报文来获取对 "https" 资源的访问。

"Connection" 头字段允许发送方列出当前连接所期望的控制选项。

  Connection        = #connection-option
  connection-option = token

连接选项不区分大小写。

当除 Connection 之外的字段用于为当前连接提供控制信息时，发送方 MUST 在 Connection 头字段中列出相应的字段名。注意某些 HTTP 版本禁止使用字段来传达此类信息，因此也不允许 Connection 字段。

中间件在转发消息之前 MUST 解析收到的 Connection 头字段，并对该字段中的每个 connection-option，从消息中移除与该 connection-option 同名的任何头字段或尾字段，然后移除 Connection 头字段本身（或以中间件为转发消息设置的控制选项替换之）。

因此，Connection 头字段提供了一种声明性方式，用以区分仅针对直接接收方（“hop-by-hop”）的字段与针对链上所有接收方（“end-to-end”）的字段，使消息具有自描述性，并允许在不担心旧中间件盲目转发的情况下部署将来针对连接的扩展。

• Proxy-Connection（参见 附录 C.2.2 的 [HTTP/1.1]）
• Keep-Alive（参见 RFC2068 第 19.7.1 节）
• TE（第 10.1.4 节）
• Transfer-Encoding（参见 第 6.1 节 的 [HTTP/1.1]）
• Upgrade（参见 第 7.8 节）

发送方 MUST NOT 发送对应于面向所有内容接收方的字段的连接选项。例如，Cache-Control 从不适合作为连接选项（见 第 5.2 节 的 [CACHING]）。

连接选项并不总是对应于消息中存在的字段，因为如果连接选项没有关联参数，则可能不需要连接特定字段。相反，如果收到连接特定字段但没有相应的连接选项，通常表明该字段被中间件错误地转发，应由接收方忽略。

在定义新的不对应字段的连接选项时，规范作者应当仍然保留相应的字段名以避免将来的冲突。这类保留字段名在 “Hypertext Transfer Protocol (HTTP) Field Name Registry”（第 16.3.1 节）中注册。

"Max-Forwards" 头字段为 TRACE（第 9.3.8 节）和 OPTIONS（第 9.3.7 节）请求方法提供了一种机制，用于限制请求被代理转发的次数。当客户端尝试跟踪似乎在链中失败或循环的请求时，这会很有用。

  Max-Forwards = 1*DIGIT

Max-Forwards 的值是一个十进制整数，指示该请求报文可以被转发的剩余次数。

每个接收到包含 Max-Forwards 头字段的 TRACE 或 OPTIONS 请求的中间件 MUST 在转发请求之前检查并更新其值。如果接收到的值为零 (0)，中间件 MUST NOT 转发请求；相反，中间件 MUST 作为最终接收方进行响应。如果接收到的 Max-Forwards 值大于零，中间件 MUST 在转发的报文中生成一个更新后的 Max-Forwards 字段，其字段值为 a) 接收值减一 或 b) 接收方对 Max-Forwards 支持的最大值，两者中较小者。

接收方 MAY 忽略在其他请求方法中收到的 Max-Forwards 头字段。

"Via" 头字段指示用户代理与服务器之间（在请求上）或源服务器与客户端之间（在响应上）存在的中间协议和接收方，类似于电子邮件中的 "Received" 头字段（参见 RFC5322 第 3.6.7 节）。Via 可用于跟踪消息转发、避免请求循环以及识别请求/响应链上发送方的协议能力。

  Via = #( received-protocol RWS received-by [ RWS comment ] )

  received-protocol = [ protocol-name "/" ] protocol-version
                    ; see Section 7.8
  received-by       = pseudonym [ ":" port ]
  pseudonym         = token

Via 字段值的每个成员表示已转发该消息的代理或网关。每个中间件追加其关于消息接收方式的信息，最终结果按转发接收方的顺序排列。

代理 MUST 在其转发的每个消息中发送适当的 Via 头字段，如下所述。HTTP 到 HTTP 的网关 MUST 在每个入站请求消息中发送适当的 Via 头字段，并且在转发的响应消息中 MAY 发送 Via 头字段。

对于每个中间件，received-protocol 指示上游发送该消息时使用的协议和协议版本。因此，Via 字段值记录了请求/响应链上声明的协议能力，使其对下游接收方可见；这对于决定在响应中或后续请求中使用哪些向后不兼容的特性可能是安全的很有用。如需简洁，当 received-protocol 为 HTTP 时可省略 protocol-name。

received-by 部分通常为随后转发消息的接收方服务器或客户端的主机及可选端口号。然而，如果真实主机被认为是敏感信息，发送方 MAY 用伪名替换之。如果未提供端口，接收方 MAY 将其解释为在 received-protocol 的默认端口（如果有）上接收。

发送方 MAY 生成注释以标识每个接收方的软件，类似于 User-Agent 和 Server 头字段。然而，Via 中的注释是可选的，接收方 MAY 在转发消息之前移除它们。

Via: 1.0 fred, 1.1 p.example.net

充当网络防火墙门户的中间件 SHOULD NOT 转发防火墙区域内主机的名称和端口，除非已显式启用此行为。如果未启用，此类中间件 SHOULD 将接收到的任何来自防火墙内部主机的 received-by 主机替换为该主机的适当伪名。

中间件 MAY 将 Via 头字段列表中具有相同 received-protocol 值的有序子序列合并为单个成员。例如，

Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

可以折叠为

Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

发送方 SHOULD NOT 合并多个列表成员，除非它们均在相同的组织控制之下且主机已被替换为伪名。发送方 MUST NOT 合并具有不同 received-protocol 值的成员。

HTTP 在 Content-Type（第 8.3 节）和 Accept（第 12.5.1 节） 头字段中使用媒体类型（参见 RFC2046），以提供开放且可扩展的数据类型和类型协商。媒体类型定义数据格式及各种处理模型：根据报文上下文如何处理该数据。

  media-type = type "/" subtype parameters
  type       = token
  subtype    = token

type 和 subtype 标记不区分大小写。

type/subtype MAY 后跟以分号分隔的参数（见 第 5.6.6 节），以 name/value 对形式出现。参数的有无可能对媒体类型的处理有重要意义，取决于其在媒体类型注册表中的定义。参数值可能区分大小写，也可能不区分，取决于参数名的语义。

  text/html;charset=utf-8
  Text/HTML;Charset="utf-8"
  text/html; charset="utf-8"
  text/html;charset=UTF-8

媒体类型应根据 [BCP13] 中定义的程序向 IANA 注册。

HTTP 使用 charset 名称来指示或协商文本表示的字符编码方案（参见 RFC6365 第 2 节）。在本文档定义的字段中，charset 名称要么出现在参数中（如 Content-Type），要么在 Accept-Encoding 中作为普通 token 出现。在两种情况下，charset 名称都是不区分大小写匹配的。

字符集名称应按照 RFC2978 第 2 节中定义的程序在 IANA 的 "Character Sets" 注册表中注册（见 https://www.iana.org/assignments/character-sets）。

MIME 提供多种 "multipart" 类型 —— 在单个消息体中封装一个或多个表示。所有 multipart 类型共享一个通用语法（参见 RFC2046 第 5.1.1 节），并在媒体类型值中包含 boundary 参数。消息体本身是一个协议元素；发送方 MUST 仅生成 CRLF 来表示各个主体部分之间的换行。

HTTP 报文分帧并不使用 multipart 边界作为消息体长度的指示，尽管生成或处理内容的实现可能会使用它。例如，"multipart/form-data" 类型经常用于在请求中携带表单数据（参见 RFC7578），而 "multipart/byteranges" 类型由本规范定义，用于某些 206 (Partial Content) 响应（参见 第 15.3.7 节）。

Content coding 值指示已对表示应用或可应用的编码变换。Content codings 主要用于允许对表示进行压缩或以其他有用方式变换而不丢失其底层媒体类型标识且无信息损失。通常，表示以编码形式存储并直接传输，只有最终接收方才解码。

  content-coding   = token

所有 content codings 不区分大小写，并应在 “HTTP Content Coding Registry” 中注册（见 第 16.6 节）。

content-coding 值用于 Accept-Encoding（第 12.5.3 节）和 Content-Encoding（第 8.4 节） 头字段。

语言标签按 RFC5646 定义，用以标识人类用于交流信息的自然语言（口语、书写或其他方式）。明确排除了计算机语言。

HTTP 在 Accept-Language 和 Content-Language 头字段中使用语言标签。Accept-Language 使用更宽泛的 language-range 产生式（见第 12.5.4 节），而 Content-Language 使用下文定义的 language-tag 产生式。

  language-tag = <Language-Tag, see [RFC5646], Section 2.1>

  fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN

更多信息请参见 RFC5646。

验证器有两种类型：strong 或 weak。弱验证器易于生成但用于比较时用途较少。强验证器适合比较但可能非常难以（有时甚至不可能）高效生成。HTTP 通过暴露使用的验证器类型并对何时可以将弱验证器用作前置条件施加限制，从而避免要求所有资源都使用相同强度的验证器。

strong validator 是这样的表示元数据：只要对在对 GET 的 200 (OK) 响应内容中可观察到的表示数据发生任何更改，其值就会改变。

强验证器可能因表示元数据的语义性变更而改变（例如 Content-Type），但源服务器应尽量仅在需要使远端缓存和创作工具中的存储响应失效时才更改其值。

缓存条目可能会长期存在，不论过期时间如何。因此，缓存可能尝试使用在遥远过去获得的验证器来验证条目。强验证器在时间上对与特定资源相关的所有表示版本都是唯一的。然而，这并不意味着跨不同资源的表示唯一（即相同的强验证器可同时用于多个资源的表示，并不意味着这些表示等同）。

实践中存在多种强验证器。最佳方式基于严格的版本控制：每一次对表示的更改都会在表示对外可见之前分配唯一的节点名和修订标识符。如果在发送响应头字段之前可获得数据并且摘要不需要在每次验证请求时重新计算，则对表示内容应用抗碰撞哈希函数亦能胜任。然而，如果资源具有仅在元数据上不同但数据格式相同的不同表示（例如在内容协商时），源服务器需要在验证器中加入额外信息以区分这些表示。

相反，weak validator 是可能不会在表示数据每次更改时都改变的表示元数据。这种弱性可能源于计算值的限制（例如时钟分辨率）、无法确保对资源所有可能表示的唯一性，或资源所有者希望将表示按某个自定的等价集合进行分组而非按数据序列唯一区分。

源服务器 SHOULD 在其认为旧的表示不再可接受作为当前表示替代时更改弱实体标签。换言之，当源服务器希望缓存使旧响应失效时，应更改弱实体标签。

例如，天气报告的表示可能每秒变化一次。源服务器可能将这些表示分组并对每组使用相同弱验证器，以允许缓存表示在合理时间内有效（可根据服务器负载或天气质量动态调整）。同样，如果表示的修改时间仅以秒为单位分辨，则当表示在同一秒内被修改两次并在这些修改之间检索时，修改时间可能是弱验证器。

如果某资源的两个或多个同时存在的表示共享相同验证器，则该验证器为弱，除非这些表示在表示数据上完全相同。例如，如果源服务器为带有 gzip 内容编码的表示与未做内容编码的表示发送相同验证器，则该验证器为弱。然而，如果两个同时存在的表示仅在表示元数据上不同（例如两种不同媒体类型对相同表示数据），它们可能共享相同的强验证器。

强验证器可用于所有条件请求，包括缓存验证、部分内容范围请求和防止“丢失更新”。弱验证器仅在客户端不要求与先前获得的表示数据完全相等时可用，例如在验证缓存条目或限制 Web 遍历为最近更改时使用。

响应中的 “Last-Modified” 头字段提供一个时间戳，指示源服务器在处理请求结束时认为所 selected representation 最后被修改的日期和时间。

  Last-Modified = HTTP-date

示例：

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

响应中的 “ETag” 字段提供所 selected representation 的当前实体标签，该标签在处理请求结束时确定。实体标签是不透明的验证器，用于区分同一资源的多个表示，无论这些不同表示是由于资源状态随时间变化、内容协商导致同一时间存在多个有效表示，还是两者兼而有之。实体标签由一个不透明的带引号字符串组成，可能以弱指示器为前缀。

  ETag       = entity-tag

  entity-tag = [ weak ] opaque-tag
  weak       = %s"W/"
  opaque-tag = DQUOTE *etagc DQUOTE
  etagc      = %x21 / %x23-7E / obs-text
             ; VCHAR except double quotes, plus obs-text

在某些情况下，实体标签比修改日期更可靠，例如当存储修改日期不便、HTTP-date 的一秒分辨率不足或修改日期未被一致维护时。

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

实体标签可以是弱或强验证器，默认是强。如果源服务器为某表示提供实体标签且生成该实体标签的方式不满足强验证器的全部特性（见第 8.8.1 节），则源服务器 MUST 通过在不透明值前加上 "W/"（区分大小写）来将该实体标签标记为弱。

发送方 MAY 在尾部部分发送 ETag 字段（见第 6.5 节）。但由于尾部常被忽略，除非实体标签在发送内容时生成，否则优先将 ETag 作为头字段发送。

如果某些请求方法的定义语义基本上为只读，则认为这些方法是 safe；即客户端既不请求也不期望在对目标资源应用安全方法时原点服务器发生任何状态更改。同样，对安全方法的合理使用不应导致任何损害、财产损失或对原点服务器造成不寻常的负担。

对安全方法的此定义并不阻止实现包含潜在有害、非完全只读或在调用安全方法时引起副作用的行为。然而重要的是，客户端并未请求这些额外行为，因此不能为其负责。例如，大多数服务器在完成每个响应时都会将请求信息追加到访问日志文件中，尽管这被认为是安全的，但日志存储可能会填满并导致服务器失败。同样，用户单击网页上的广告通常会产生计费到广告账户的副作用。

在本规范定义的请求方法中，GET、HEAD、OPTIONS 和 TRACE 方法被定义为安全方法。

区分安全与不安全方法的目的是允许自动检索过程（爬虫）和缓存性能优化（预取）在不致造成危害的情况下工作。此外，这还允许用户代理在处理可能不可信内容时对不安全方法的自动使用施加适当约束。

用户代理在向用户呈现潜在操作时 SHOULD 区分安全与不安全方法，以便在请求不安全操作之前使用户能够意识到该操作的不安全性。

当资源被构造为使目标 URI 内的参数具有选择某个动作的效果时，资源所有者有责任确保该动作与请求方法语义一致。例如，网页编辑软件常在查询参数中使用类似 "page?do=delete" 的动作。如果此类资源的目的是执行不安全操作，则资源所有者 MUST 在通过安全请求方法访问时禁用或拒绝该动作。否则，当自动化进程为了链接维护、预取、构建搜索索引等目的对每个 URI 引用执行 GET 时，将产生不良副作用。

如果对服务器的多次相同请求所产生的预期效果与对该方法的一次请求相同，则认为该请求方法是 idempotent（幂等）。在本规范定义的方法中，PUT、DELETE 以及安全请求方法均为幂等。

与安全性定义类似，幂等属性仅适用于用户请求所要求的内容；服务器可以为每个幂等请求单独记录日志、保留修订控制历史或实现其他非幂等的副作用。

幂等方法之所以被区分，是因为如果在客户端在读取服务器响应之前发生通信失败，请求可以被自动重复。例如，如果客户端发送了一个 PUT 请求且底层连接在接收任何响应之前关闭，则客户端可以建立新连接并重试该幂等请求。客户端知道重复该请求将产生相同的预期效果，即使原始请求已成功，响应也可能不同。

除非客户端有某种手段确定请求语义实际上是幂等的（与方法无关），或有手段检测原始请求从未被应用，否则客户端 SHOULD NOT 自动重试非幂等方法的请求。

例如，如果用户代理通过设计或配置知道对该资源的 POST 请求是安全的，则可以自动重复该 POST 请求。同样，专门针对版本控制仓库设计的用户代理可能通过在失败连接后检查目标资源的修订、回退或修复任何部分应用的更改，然后自动重试失败的请求，从而从部分失败条件中恢复。

有些客户端采取更冒险的做法并尝试猜测何时可以自动重试。例如，如果底层传输连接在未接收任何响应部分之前关闭，客户端可能会自动重试 POST 请求，特别是在使用空闲的持久连接时。

代理 MUST NOT 自动重试非幂等请求。客户端 SHOULD NOT 自动重试已失败的自动重试。

要使缓存存储并使用一个响应，相关的方法需要明确允许缓存并详细说明在何种条件下响应可用于满足后续请求；未做此说明的方法定义则不能被缓存。有关附加要求，请参见 [CACHING]。

本规范为 GET、HEAD 和 POST 定义了缓存语义，尽管绝大多数缓存实现仅支持 GET 和 HEAD。

GET 方法请求传输目标资源的当前 所选表示。成功响应应反映目标 URI 所识别的“等同性”质量（参见 URI 第 1.2.2 节）。因此，通过 HTTP 检索可识别信息通常是通过对与该信息提供潜力相关的标识符发起 GET 请求来完成的（并期望得到 200 (OK) 响应）。

GET 是信息检索的主要机制，也是几乎所有性能优化的关注点。为每个重要资源生成 URI 的应用能够受益于这些优化，同时让其他应用重用这些 URI，从而产生促进 Web 扩展的网络效应。

将资源标识符视为远程文件系统路径名并将表示视为这些文件内容副本是很诱人的想法。事实上，许多资源确实如此实现（参见与文件和路径名相关的攻击安全考虑 第 17.3 节）。然而在实践中并无此类限制。

资源的 HTTP 接口同样可能实现为内容对象树、对各种数据库记录的程序化视图，或通向其他信息系统的网关。即便 URI 映射机制与文件系统相关联，源服务器也可能配置为在接收请求时执行这些文件并将其输出作为表示发送，而不是直接传输文件。无论如何，只有源服务器需要知道每个资源标识符如何对应于某个实现，以及该实现如何选择并发送目标资源的当前表示。

客户端可以通过在请求中发送 Range 头字段（第 14.2 节）将 GET 的语义更改为“范围请求”，以请求仅传输所选表示的部分内容。

尽管请求消息分帧与所使用的方法无关，但在 GET 请求中接收的内容没有通用定义的语义，不能改变请求的含义或目标，并且可能导致某些实现拒绝该请求并关闭连接，因为它可能被用于请求走私攻击（参见 HTTP/1.1 第 11.2 节）。客户端 SHOULD NOT 在 GET 请求中生成内容，除非该请求直接发向已事先明确（带内或带外）表明此类请求有意义并会被充分支持的源服务器。源服务器 SHOULD NOT 依赖私有协议来接收内容，因为 HTTP 通信的参与者通常并不了解沿请求链的中间件。

对 GET 请求的响应是可缓存的；缓存 MAY 将其用于满足后续的 GET 和 HEAD 请求，除非由 Cache-Control 头字段另有指示（参见 第 5.2 节）。

当使用从用户提供信息构造目标 URI 的机制执行信息检索时（例如使用 GET 的表单查询字段），可能会提供不应在 URI 中披露的敏感数据（见 第 17.9 节）。在某些情况下，可以对数据进行过滤或转换以避免泄露。在其他情况下，尤其当没有缓存响应的好处时，使用 POST 方法（第 9.3.3 节）而不是 GET，可将此类信息放在请求内容中而不是目标 URI 中传输。

HEAD 方法与 GET 相同，不同之处在于服务器 MUST NOT 在响应中发送内容。HEAD 用于在不传输表示数据的情况下获取所选表示的元数据，通常用于测试超文本链接或查找最近的修改情况。

服务器 SHOULD 在响应 HEAD 请求时发送与如果方法为 GET 时相同的头字段。然而，服务器 MAY 省略那些只有在生成内容时才能确定其值的头字段。例如，一些服务器会缓冲动态 GET 响应直到生成最小量的数据，以便更高效地定界小响应或在内容选择上做出延迟决定。因此，对 GET 的响应可能包含 Content-Length 与 Vary 字段，而这些字段可能不会在 HEAD 响应中生成。与为 HEAD 请求生成并丢弃内容相比，这些小不一致被视为更可取，因为 HEAD 通常用于提高效率。

尽管请求消息分帧与所用方法独立，但在 HEAD 请求中接收的内容没有通用定义的语义，不能改变请求的含义或目标，且可能导致某些实现因其作为请求走私攻击的可能性而拒绝请求并关闭连接（参见 第 11.2 节）。客户端 SHOULD NOT 在 HEAD 请求中生成内容，除非该请求直接发向已事先明确表明此类请求有意义并会被充分支持的源服务器。源服务器 SHOULD NOT 依赖私有协议来接收内容。

对 HEAD 请求的响应是可缓存的；缓存 MAY 将其用于满足后续的 HEAD 请求，除非由 Cache-Control 头字段另有指示（参见 第 5.2 节）。HEAD 响应也可能影响先前对 GET 的缓存响应；详见 第 4.3.5 节。

• 向数据处理过程提供一块数据，例如在 HTML 表单中输入的字段；
• 向公告板、新闻组、邮件列表、博客或类似的文章组发布消息；
• 创建尚未由源服务器识别的新资源；以及
• 向资源的现有表示追加数据。

源服务器通过根据处理 POST 请求的结果选择适当的状态码来指示响应语义；几乎本规范定义的所有状态码都可能在对 POST 的响应中出现（例外为 206 (Partial Content)、304 (Not Modified) 和 416 (Range Not Satisfiable)）。

如果一个或多个资源在源服务器上因成功处理 POST 请求而被创建，源服务器 SHOULD 发送一个包含 201 (Created) 的响应，其中应包含提供主创建资源标识符的 Location 头字段（见 第 10.2.2 节），以及一个描述请求状态并引用新资源的表示。

只有当包含明确的新鲜度信息（参见 第 4.2.1 节）并且 Content-Location 头字段与 POST 的目标 URI 相同（参见 第 8.7 节）时，POST 的响应才是可缓存的。缓存的 POST 响应可用于满足后续的 GET 或 HEAD 请求。相反，POST 请求不能由缓存的 POST 响应来满足，因为 POST 可能不安全；参见 第 4 节。

如果处理 POST 的结果等同于现有资源的某个表示，源服务器 MAY 通过发送带有现有资源标识符的 303 (See Other) 响应（并在 Location 字段中提供该标识符）将用户代理重定向到该资源。这样做的好处是为用户代理提供了一个资源标识符并通过更适合共享缓存的方法传输表示，尽管如果用户代理未缓存该表示，则增加一次请求成本。

PUT 方法请求用请求消息内容中包含的表示所定义的状态来创建或替换目标资源的状态。对于给定表示的成功 PUT，表明随后对相同目标资源的 GET 请求将返回等效的表示（并以 200 (OK) 响应）。然而，这并不保证这样的状态更改会被观察到，因为目标资源可能在随后 GET 到达之前被其他用户代理并行操作，或被源服务器进行动态处理。成功响应仅意味着在源服务器处理时用户代理的意图已被实现。

如果目标资源当前没有表示且 PUT 成功创建了一个，源服务器 MUST 通过发送 201 (Created) 响应通知用户代理。如果目标资源已有当前表示且该表示按所封装表示的状态成功修改，则源服务器 MUST 发送 200 (OK) 或 204 (No Content) 响应以指示请求成功完成。

源服务器 SHOULD 验证 PUT 表示是否与目标资源的配置约束一致。例如，如果源服务器根据 URI 确定资源的表示元数据，则源服务器需要确保在成功的 PUT 请求中接收的内容与该元数据一致。当 PUT 表示与目标资源不一致时，源服务器 SHOULD 通过转换表示或更改资源配置使其一致，或返回包含足够信息以解释为何该表示不合适的适当错误消息。建议使用 409 (Conflict) 或 415 (Unsupported Media Type) 状态码，后者专用于对 Content-Type 值的限制。

1. 重新配置目标资源以反映新的媒体类型；
2. 在保存为新的资源状态之前将 PUT 表示转换为与资源一致的格式；或，
3. 以 415 (Unsupported Media Type) 响应拒绝请求，表明目标资源仅限于 "text/html"，并可能包含指向适于新表示的其他资源的链接。

HTTP 并未精确定义 PUT 方法如何影响源服务器状态，超出用户代理请求意图和源服务器响应语义所能表达的范围。它不定义资源在任何意义上的具体含义，也不定义资源状态如何“存储”、这种存储如何因状态更改而改变或源服务器如何将资源状态翻译为表示。一般而言，服务器隐藏了资源接口背后的所有实现细节。

这同样适用于头字段和尾字段的存储处理；虽然像 Content-Type 这样的常见头字段通常会被存储并在随后的 GET 请求中返回，但头字段和尾字段的处理取决于接收请求的资源。因此，源服务器 SHOULD 忽略在 PUT 请求中接收到的未识别头字段和尾字段（即不将其作为资源状态的一部分保存）。

源服务器 MUST NOT 在对 PUT 的成功响应中发送验证器字段（见 第 8.8 节），例如 ETag 或 Last-Modified，除非请求的表示数据在保存时未对内容进行任何转换（即资源的新表示数据与 PUT 请求接收的内容相同），且验证器字段值反映了该新表示。此要求允许用户代理在发送并保留在内存中的表示即为 PUT 的结果时得知不必再次从源服务器检索表示。响应中收到的新验证器可用于未来的条件请求以防止意外覆盖（见 第 13.1 节）。

POST 与 PUT 方法之间的根本区别在于对所封装表示的不同意图：POST 的目标资源旨在根据资源自身的语义处理封装表示，而 PUT 请求中封装的表示被定义为替换目标资源的状态。因此，PUT 的意图是幂等的并对中间件可见，尽管确切效果仅由源服务器知晓。

对 PUT 请求的正确解释假设用户代理知道期望的目标资源。若服务在接收状态更改请求后代客户选择合适的 URI，则应使用 POST 而非 PUT 来实现。如果源服务器不会对目标资源执行请求的 PUT 状态更改而希望将其应用到另一个资源（例如当资源已被移到不同 URI 时），则源服务器 MUST 发送适当的 3xx (Redirection) 响应；用户代理 MAY 自行决定是否重定向请求。

对目标资源应用的 PUT 请求可能对其他资源产生副作用。例如，文章可能有一个用于标识“当前版本”的 URI（一个资源），它与识别每个特定版本的 URI（不同资源）是分离的。对“当前版本” URI 的成功 PUT 请求可能因此创建一个新的版本资源，除了更改目标资源的状态外，还可能在相关资源之间添加链接。

一些源服务器支持将 Content-Range 头字段（见 第 14.4 节）用作请求修改器来执行部分 PUT，如 第 14.5 节 所述。

对 PUT 方法的响应不可缓存。如果成功的 PUT 请求通过了具有目标 URI 的一个或多个已存储响应的缓存，则这些已存储的响应将被失效（参见 第 4.4 节）。

DELETE 方法请求源服务器移除目标资源与其当前功能之间的关联。实际上，该方法类似于 UNIX 中的 "rm" 命令：它表示对源服务器的 URI 映射执行删除操作，而不是期望之前关联的信息被物理删除。

如果目标资源具有一个或多个当前表示，这些表示可能会也可能不会被源服务器销毁，相关存储也可能会也可能不会被回收，这完全取决于资源的性质及其由源服务器的实现（超出本规范范围）。同样，资源的其他实现方面可能需要在 DELETE 后被停用或存档，例如数据库或网关连接。一般假设源服务器仅在其具有实现删除机制的资源上允许 DELETE。

允许 DELETE 的资源相对较少——其主要用途是远程作者环境，在那里用户对其效果有一定指示。例如，先前通过 PUT 创建或在对 POST 的 201 (Created) 响应后的 Location 头字段所标识的资源，可能允许相应的 DELETE 请求撤销那些操作。同样，实现作者功能的自定义用户代理（如使用 HTTP 执行远程操作的修订控制客户端）可能在假设服务器的 URI 空间已被设计为对应版本仓库时使用 DELETE。

如果成功应用 DELETE 方法，源服务器 SHOULD 发送：

• 如果该操作可能会成功但尚未生效，则发送 202 (Accepted)；
• 如果该操作已生效且不需提供进一步信息，则发送 204 (No Content)；或
• 如果该操作已生效且响应消息包含描述状态的表示，则发送 200 (OK)。

尽管请求消息分帧与所用方法独立，但在 DELETE 请求中接收的内容没有通用定义的语义，不能改变请求的含义或目标，并且可能导致某些实现因其作为请求走私攻击的潜在用途而拒绝请求并关闭连接（参见 第 11.2 节）。客户端 SHOULD NOT 在 DELETE 请求中生成内容，除非该请求直接发向已事先明确表明此类请求有意义并会被充分支持的源服务器。源服务器 SHOULD NOT 依赖私有协议来接收内容。

对 DELETE 方法的响应不可缓存。如果成功的 DELETE 请求通过了具有目标 URI 的一个或多个已存储响应的缓存，则这些已存储的响应将被失效（参见 第 4.4 节）。

CONNECT 方法请求接收者为请求目标所标识的目的地源服务器建立隧道，如果成功，随后将其行为限制为盲转发数据（双向），直到隧道关闭为止。隧道通常用于通过一个或多个代理创建端到端的虚拟连接，然后可以使用 TLS（传输层安全，参见 TLS13）对其进行保护。

CONNECT 使用一种对该方法唯一的特殊请求目标形式，仅由隧道目的地的主机和端口号组成，两者以冒号分隔。没有默认端口；客户端 MUST 发送端口号，即便 CONNECT 请求基于包含省略端口的 authority 分量的 URI 引用（参见 第 4.1 节）。例如：

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com

服务器 MUST 拒绝目标为空或无效端口号的 CONNECT 请求，通常以 400 (Bad Request) 状态码响应。

由于 CONNECT 会改变 HTTP 连接的请求/响应性质，具体 HTTP 版本可能对其语义到协议线格式的映射方式不同。

CONNECT 旨在用于对代理的请求。接收者可以通过直接连接到请求目标所标识的服务器来建立隧道，或在配置为使用另一个代理时将 CONNECT 请求转发给下一个入站代理。源服务器 MAY 接受 CONNECT 请求，但大多数源服务器并不实现 CONNECT。

任何 2xx (Successful) 响应表明发送方（以及所有入站代理）将在响应头部部分之后立即切换到隧道模式；在该头部部分之后接收的数据即来自请求目标所标识的服务器。任何非成功响应表明隧道尚未形成。

当隧道中间件检测到任一侧关闭其连接时，隧道即被关闭：中间件 MUST 尝试将来自已关闭一侧的任何未发送数据发送到另一侧，关闭两个连接，然后丢弃任何剩余未交付的数据。

可能使用代理认证来建立创建隧道的权限。例如：

CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443
Proxy-Authorization: basic aGVsbG86d29ybGQ=

对任意服务器建立隧道存在重大风险，尤其当目的地为并非为 Web 流量设计的知名或保留 TCP 端口时。例如，CONNECT 到 "example.com:25" 会暗示代理连接到用于 SMTP 流量的保留端口；若允许，可能会欺骗代理中继垃圾邮件。支持 CONNECT 的代理 SHOULD 将其使用限制在已知端口的有限集合或可配置的安全目标列表中。

服务器 MUST NOT 在对 CONNECT 的 2xx (Successful) 响应中发送任何 Transfer-Encoding 或 Content-Length 头字段。客户端 MUST 忽略在对 CONNECT 的成功响应中接收的任何 Content-Length 或 Transfer-Encoding 头字段。

CONNECT 请求消息没有内容。CONNECT 请求消息头部部分之后发送的数据的解释取决于所使用的 HTTP 版本。

对 CONNECT 方法的响应不可缓存。

OPTIONS 方法请求有关目标资源在源服务器或中间代理处可用的通信选项的信息。该方法允许客户端确定与资源相关的选项和/或要求，或服务器的能力，而不暗含对资源执行操作。

以星号 ("*") 作为请求目标的 OPTIONS 请求（参见 第 7.1 节）适用于服务器整体而非特定资源。由于服务器的通信选项通常取决于资源，“*” 请求仅作为一种“ping”或“无操作”类型的方法有用；它仅允许客户端测试服务器的能力，例如测试代理对 HTTP/1.1 的兼容性（或不兼容性）。

如果请求目标不是星号，则 OPTIONS 请求适用于与目标资源通信时可用的选项。

生成 OPTIONS 成功响应的服务器 SHOULD 发送任何可能指示服务器实现的并适用于目标资源的可选功能的头字段（例如 Allow），包括本规范未定义的潜在扩展。响应内容（如果有）也可用机器或人可读的表示描述通信选项。本规范并未定义此类表示的标准格式，但未来的 HTTP 扩展可能会定义。

客户端 MAY 在 OPTIONS 请求中发送 Max-Forwards 头字段以定位请求链中的特定接收者（参见 第 7.6.2 节）。代理 MUST NOT 在转发请求时生成 Max-Forwards 头字段，除非该请求在接收时已包含 Max-Forwards 字段。

在 OPTIONS 请求中包含内容的客户端 MUST 发送有效的 Content-Type 头字段以描述所表示的媒体类型。注意，本规范并未为此类内容定义任何用途。

对 OPTIONS 方法的响应不可缓存。

TRACE 方法请求对请求消息进行远程应用层回环。请求的最终接收者 SHOULD 将其接收到的消息（排除下面描述的某些字段）反射回客户端，作为 200 (OK) 响应的内容。使用 "message/http" 格式（见 第 10.1 节）是一种实现方式。请求的最终接收者要么是源服务器，要么是请求中 Max-Forwards 值为零 (0) 的第一个服务器（见 第 7.6.2 节）。

客户端 MUST NOT 在 TRACE 请求中生成可能被响应泄露的包含敏感数据的字段。例如，用户代理不应在 TRACE 请求中发送存储的用户凭证（见 第 11 节）或 Cookie（参见 COOKIE）。请求的最终接收者在生成响应内容时 SHOULD 排除任何可能包含敏感数据的请求字段。

TRACE 允许客户端查看在请求链另一端接收到的内容并将其用于测试或诊断信息。Via 头字段的值尤其值得关注，因为它作为请求链的跟踪。使用 Max-Forwards 头字段允许客户端限制请求链的长度，这对于测试可能在循环中转发消息的一系列代理非常有用。

客户端 MUST NOT 在 TRACE 请求中发送内容。

对 TRACE 方法的响应不可缓存。

请求中的 "Expect" 头字段指示一组行为（期望），服务器必须支持这些行为以便正确处理该请求。

  Expect =      #expectation
  expectation = token [ "=" ( token / quoted-string ) parameters ]

Expect 字段值不区分大小写。

本规范定义的唯一期望是 "100-continue"（无定义参数）。

收到包含除 100-continue 之外成员的 Expect 字段值的服务器 MAY 使用 417 (Expectation Failed) 状态码响应，以表示无法满足该意外期望。

100-continue 期望告知接收方客户端即将发送（通常是较大）内容，并希望在方法、目标 URI 和头字段不足以导致立即的成功、重定向或错误响应时接收一个 100 (Continue) 中间响应。这允许客户端在真正发送大量数据之前先等待是否值得发送，有助于在数据巨大或客户端预期可能发生错误时提高效率（例如在首次发送状态改变的方法但尚未验证认证凭据时）。

例如，下述以...

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue

允许源服务器在客户端开始耗费带宽传输大量数据之前立即返回错误消息，例如 401 (Unauthorized) 或 405 (Method Not Allowed)。

• 客户端在请求不包含内容时 MUST NOT 生成 100-continue 期望。
• 将会在发送请求内容之前等待 100 (Continue) 响应的客户端 MUST 发送包含 100-continue 期望的 Expect 头字段。
• 发送 100-continue 期望的客户端并不要求等待特定的时间；这样的客户端 MAY 即使尚未收到响应也继续发送内容。此外，由于 100 (Continue) 响应无法通过 HTTP/1.0 中间件发送，客户端 SHOULD NOT 在发送内容之前无限期等待。
• 在收到对包含 100-continue 期望的请求的响应为 417 (Expectation Failed) 时，客户端 SHOULD 重复该请求但不带 100-continue 期望，因为 417 响应仅表示响应链不支持期望（例如它通过了一个 HTTP/1.0 服务器）。

• 在收到 HTTP/1.0 请求中的 100-continue 期望时，服务器 MUST 忽略该期望。
• 服务器 MAY 在已接收部分或全部对应请求的内容时，或帧定界表明没有内容时，省略发送 100 (Continue) 响应。
• 发送 100 (Continue) 响应的服务器 MUST 在接收并处理请求内容后最终发送一个最终状态码，除非连接被提前关闭。
• 在在读取完整请求内容之前就返回最终状态码的服务器 SHOULD 指示它是否打算关闭连接（例如参见 HTTP/1.1 第 9.6 节），或继续读取请求内容。

• 如果仅通过检查方法、目标 URI 与头字段即可确定最终状态，则立即发送该最终状态码的响应，或
• 发送一个立即的 100 (Continue) 响应以鼓励客户端发送请求内容。

源服务器 MUST NOT 在发送 100 (Continue) 响应之前等待内容。

• 如果仅通过检查方法、目标 URI 与头字段即可确定最终状态，则发送一个立即的最终状态码响应，或
• 通过向下一个入站服务器发送相应的请求行和头部部分将请求转发给源服务器。

如果代理基于配置或过往交互认为下一个入站服务器仅支持 HTTP/1.0，则代理 MAY 生成一个立即的 100 (Continue) 响应以鼓励客户端开始发送内容。

  From    = mailbox

  mailbox = <mailbox, see [RFC5322], Section 3.4>

From: spider-admin@example.org

非机器人用户代理很少发送 From 头字段。用户代理在未获得用户明确配置时 SHOULD NOT 发送 From 头字段，因为这可能与用户的隐私利益或其站点的安全策略相冲突。

机器人用户代理 SHOULD 发送有效的 From 头字段，以便在服务器出现问题（例如机器人发送过多、不受欢迎或无效请求时）时能联系到负责运行该机器人的人。

服务器 SHOULD NOT 将 From 头字段用于访问控制或认证，因为其值通常对接收或观察请求的任何人可见，并且常在日志文件和错误报告中记录，无法期望其具有隐私性。

“Referer”（拼写有误，原意为 "Referrer"）头字段允许用户代理指定一个 URI 引用，表示从该资源获取了 目标 URI（即“引用者”）。用户代理 MUST NOT 在生成 Referer 字段值时包含 URI 引用的 fragment 和 userinfo 分量（如有）。

  Referer = absolute-URI / partial-URI

字段值要么为 absolute-URI，要么为 partial-URI。在后者情况下，所引用的 URI 相对于目标 URI（参见第 4 节）。

Referer 头字段允许服务器生成指向其他资源的回溯链接，用于简单分析、日志、优化缓存等。它也有助于发现过时或拼写错误的链接以便维护。一些服务器使用 Referer 头字段作为拒绝来自其他站点链接（所谓“深度链接”）或限制跨站请求伪造（CSRF）的一种手段，但并非所有请求都包含该字段。

Referer: http://www.example.org/hypertext/Overview.html

如果目标 URI 是从没有自己 URI 的来源（例如用户键盘输入或用户书签/收藏中的条目）获得的，用户代理 MUST 要么省略 Referer 头字段，要么以 "about:blank" 作为其值发送。

Referer 字段值不必传达完整的引用资源 URI；用户代理 MAY 截断除了引用源（origin）之外的部分。

Referer 头字段可能泄露有关请求上下文或用户浏览历史的信息，如果引用资源标识符暴露个人信息（如账户名）或属于应保密的资源（如防火墙后或受保护服务内部），则构成隐私顾虑。大多数通用用户代理在引用资源为本地 "file" 或 "data" URI 时不会发送 Referer。用户代理 SHOULD NOT 在引用资源使用安全协议且目标请求的 origin 与引用资源不同的情况下发送 Referer，除非引用资源明确允许发送 Referer。用户代理 MUST NOT 在不安全的 HTTP 请求中发送 Referer，如果引用资源是通过安全协议访问的。有关更多安全考虑，请参见第 17.9 节。

一些中间件已知会不加区分地从外发请求中移除 Referer 头字段。这会不幸地干扰对 CSRF 攻击的防护，而 CSRF 对用户可能造成更大的危害。希望限制 Referer 信息泄露的中间件和用户代理扩展应仅限于特定编辑，例如将内部域名替换为伪名或截断查询和/或路径分量。中间件 SHOULD NOT 在字段值与目标 URI 具有相同方案和主机时修改或删除 Referer 头字段。

“TE” 头字段描述客户端关于传输编码和尾部部分的能力。

如在 第 6.5 节 所述，请求中包含有 "trailers" 成员的 TE 字段表示客户端不会丢弃尾字段。

TE 也用于在 HTTP/1.1 中告知服务器客户端能够接受响应中哪些传输编码。截至发布时，仅 HTTP/1.1 使用传输编码（参见 HTTP/1.1 第 7 节）。

TE 字段值为成员列表，除了 "trailers" 之外的每个成员由传输编码名称的 token 组成，可选地带有指示客户端对该传输编码相对偏好的权重（参见 第 12.4.2 节）以及该传输编码的可选参数。

  TE                 = #t-codings
  t-codings          = "trailers" / ( transfer-coding [ weight ] )
  transfer-coding    = token *( OWS ";" OWS transfer-parameter )
  transfer-parameter = token BWS "=" BWS ( token / quoted-string )

TE 的发送方 MUST 还在 Connection 头字段中发送一个 "TE" 连接选项（见 第 7.6.1 节），以告知中间件不要转发该字段。

“User-Agent” 头字段包含关于发起请求的用户代理的信息，服务器常用它来帮助识别互操作性问题的范围、为规避特定用户代理的限制而调整响应、以及进行有关浏览器或操作系统使用情况的分析。除非明确配置为不发送，否则用户代理 SHOULD 在每个请求中发送 User-Agent 头字段。

  User-Agent = product *( RWS ( product / comment ) )

User-Agent 字段值由一个或多个 product 标识符组成，每个后跟零个或多个注释（参见 第 5.6.5 节），共同标识用户代理软件及其重要的子产品。按惯例，product 标识符按其标识用户代理软件的重要性递减的顺序列出。每个 product 标识符由名称和可选版本组成。

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

发送方 SHOULD 将生成的 product 标识符限制为识别产品所必需的信息；发送方 MUST NOT 在 product 标识符中生成广告或其他非必要信息。发送方 SHOULD NOT 在 product-version 中生成非版本标识的信息（即同一产品名的连续版本应仅在 product-version 部分有所不同）。

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

用户代理 SHOULD NOT 生成包含不必要细粒度细节的 User-Agent 头字段，并且 SHOULD 限制第三方添加子产品。过长且过于详细的 User-Agent 字段值会增加请求延迟并提高用户被识别的风险（“指纹识别”）。

同样，鼓励实现不要使用其他实现的 product token 来声明与其兼容，因为这会规避该字段的目的。如果用户代理伪装为另一个用户代理，接收方可以假定用户有意希望看到为该被标识用户代理定制的响应，即便这些响应对于实际使用的用户代理可能并不完全合适。

“Allow” 头字段列出目标资源宣称支持的方法集合。此字段的目的仅仅是告知接收方与该资源相关的有效请求方法。

  Allow = #method

Allow: GET, HEAD, PUT

允许的方法的实际集合由源服务器在每次请求时定义。源服务器 MUST 在 405 (Method Not Allowed) 响应中生成 Allow 头字段，并且 MAY 在任何其他响应中生成。Allow 字段值为空表示该资源不允许任何方法，这可能在 405 响应中发生，例如资源被配置暂时禁用时。

代理 MUST NOT 修改 Allow 头字段——它不需要理解所有指示的方法即可根据通用消息处理规则来处理这些方法。

“Location” 头字段在某些响应中用于引用与该响应相关的特定资源。该关系的类型由请求方法和状态码语义的组合确定。

  Location = URI-reference

字段值由单个 URI-reference 组成。当其为相对引用形式时，最终值通过将其解析相对于目标 URI 来计算（参见 URI 规范）。

对于 201 (Created) 响应，Location 值指向请求所创建的主资源。对于 3xx (Redirection) 响应，Location 值指向用于自动重定向请求的首选目标资源。

如果 3xx 响应中提供的 Location 值不包含 fragment 分量，用户代理 MUST 将重定向视为如果该值继承用于生成目标 URI 的 URI 引用的 fragment（即重定向继承原始引用的 fragment（若有））。

Location: /People.html#tim

这表明用户代理应重定向到 "http://www.example.org/People.html#tim"

Location: http://www.example.net/index.html

这表明用户代理应重定向到 "http://www.example.net/index.html#larry"，保留原始的 fragment 标识符。

在某些情况下，Location 值中包含 fragment 标识符并不合适。例如，201 (Created) 响应中的 Location 头字段应提供一个特定于所创建资源的 URI。

服务器发送 "Retry-After" 头字段以指示用户代理在发起后续请求之前应等待多长时间。当与 503 (Service Unavailable) 响应一起发送时，Retry-After 指示服务预计对客户端不可用的时长。当与任何 3xx (Redirection) 响应一起发送时，Retry-After 指示要求用户代理在发起被重定向请求之前至少等待的时间。

Retry-After 字段值可以是 HTTP-date 或表示在接收响应后应延迟的秒数。

  Retry-After = HTTP-date / delay-seconds

delay-seconds 值为非负十进制整数，表示秒数。

  delay-seconds  = 1*DIGIT

两个使用示例：

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

在后一个示例中，延迟为 2 分钟。

“Server” 头字段包含源服务器用于处理请求的软件信息，客户端通常用它来帮助识别互操作性问题的范围、在发送请求时规避或针对特定服务器限制进行调整，并用于关于服务器或操作系统使用情况的分析。源服务器 MAY 在其响应中生成 Server 头字段。

  Server = product *( RWS ( product / comment ) )

Server 字段值由一个或多个 product 标识符组成，每个后跟零个或多个注释（参见 第 5.6.5 节），共同标识源服务器软件及其重要子产品。按惯例，product 标识符按其在识别源服务器软件方面的重要性递减的顺序列出。每个 product 标识符由名称和可选版本组成，如第 10.1.5 节所定义。

Server: CERN/3.0 libwww/2.17

源服务器 SHOULD NOT 生成包含不必要细粒度细节的 Server 头字段值，并且 SHOULD 限制第三方添加子产品。过长且过于详细的 Server 字段值会增加响应延迟并可能泄露内部实现细节，从而（略微）使攻击者更容易发现并利用已知安全漏洞。

"WWW-Authenticate" 响应头字段指示适用于目标资源的认证方案及其参数。

  WWW-Authenticate = #challenge

生成 401 (Unauthorized) 响应的服务器 MUST 发送一个包含至少一个质询的 WWW-Authenticate 头字段。服务器 MAY 在其他响应消息中生成 WWW-Authenticate 头字段以指示提供凭证（或不同的凭证）可能会影响响应。

转发响应的代理 MUST NOT 修改响应中的任何 WWW-Authenticate 头字段。

建议用户代理在解析该字段值时格外小心，因为它可能包含多个质询，并且每个质询可以包含以逗号分隔的认证参数列表。此外，该头字段本身也可能出现多次。

WWW-Authenticate: Basic realm="simple", Newauth realm="apps",
                 type=1, title="Login to \"apps\""

该头字段包含两个质询：一个是 "Basic" 方案并带有 realm="simple"，另一个是 "Newauth" 方案并带有 realm="apps"。它还包含两个额外参数 "type" 和 "title"。

不过，一些用户代理不识别这种形式。因此，在同一字段行上发送包含多个成员的 WWW-Authenticate 字段值可能不具互操作性。

"Authorization" 头字段允许用户代理向源服务器进行自我认证 —— 通常（但不必然）在收到 401 (Unauthorized) 响应之后。其值由包含用户代理在请求所针对领域内的认证信息的凭证组成。

  Authorization = credentials

如果请求已通过认证并指定了 realm，则假定相同凭证对该 realm 内的所有其他请求有效（前提是认证方案本身没有另行要求，例如凭证随挑战值变化或需要同步时钟的情形）。

转发请求的代理 MUST NOT 修改该请求中的任何 Authorization 头字段。有关 HTTP 缓存处理 Authorization 头字段的详细要求，请参见 CACHING 第 3.5 节。

HTTP 认证方案可以使用 "Authentication-Info" 响应字段在客户端凭证被接受之后传达信息。该信息可以包含来自服务器的最终消息（例如，它可以包含服务器的认证信息）。

字段值为参数列表（名称/值对），使用在 第 11.3 节 中定义的 "auth-param" 语法。本规范仅描述通用格式；使用 Authentication-Info 的认证方案将定义各自的参数。例如，Digest 认证方案在 RFC7616 第 3.5 节 中定义了多个参数。

  Authentication-Info = #auth-param

Authentication-Info 字段可用于任何 HTTP 响应，与请求方法和状态码无关。其语义由与对应请求相关的 Authorization 头字段所指示的认证方案定义（参见 第 11.6.2 节）。

转发响应的代理不得以任何方式修改该字段值。

当认证方案明确允许时，Authentication-Info 可以作为尾部字段发送（参见 第 6.5 节）。

"Proxy-Authenticate" 头字段由至少一个质询组成，指示适用于本次请求的代理的认证方案和参数。代理在生成的每个 407 (Proxy Authentication Required) 响应中 MUST 发送至少一个 Proxy-Authenticate 头字段。

  Proxy-Authenticate = #challenge

与 WWW-Authenticate 不同，Proxy-Authenticate 头字段仅适用于响应链中下一个出站客户端。这是因为只有选择了给定代理的客户端最可能拥有进行认证所需的凭证。然而，当多个代理位于同一管理域内（例如大型公司网络中的办公与区域缓存代理）时，通常会由用户代理生成凭证并在层级中传递直到被消费。因此，在这种配置下，看起来 Proxy-Authenticate 被转发，因为每个代理都会发送相同的质询集合。

注意：对 WWW-Authenticate 的解析注意事项同样适用于此头字段；详见 第 11.6.1 节。

"Proxy-Authorization" 头字段允许客户端向要求认证的代理标识其自身（或其用户）。其值由包含针对代理和/或所请求资源的领域的客户端认证信息的凭证组成。

  Proxy-Authorization = credentials

与 Authorization 不同，Proxy-Authorization 头字段仅适用于期待由 Proxy-Authenticate 头字段要求凭证的下一个入站代理。当链中使用多个代理时，Proxy-Authorization 头字段会被第一个期待接收凭证的入站代理消费。代理 MAY 将客户端请求中的凭证中继到下一个代理，如果这是代理之间协同认证给定请求的机制。

  Proxy-Authentication-Info = #auth-param

然而，与 Authentication-Info 不同，Proxy-Authentication-Info 头字段仅适用于响应链中的下一个出站客户端。这是因为只有选择了给定代理的客户端最可能拥有进行认证所需的凭证。然而，当多个代理位于同一管理域内（例如大型公司网络中的办公与区域缓存代理）时，通常会由用户代理生成凭证并在层级中传递直到被消费。因此，在这种配置下，看起来 Proxy-Authentication-Info 被转发，因为每个代理都会发送相同的字段值。

当认证方案明确允许时，Proxy-Authentication-Info 可以作为尾部字段发送（参见 第 6.5 节）。

对于每个内容协商字段，不包含该字段的请求表示发送方在该协商维度上没有偏好。

如果请求中存在一个内容协商头字段，且没有可用的响应表示被认为可接受，源服务器可以通过发送 406 (Not Acceptable) 响应来尊重该头字段，或者无视该头字段，将响应视为不受该请求头字段的内容协商影响。但这并不意味着客户端就一定能够使用该表示。

本规范定义的内容协商字段使用一个通用参数，名为 "q"（不区分大小写），用于为该种类内容的偏好分配相对“权重”。该权重称为“质量值”（或“qvalue”），因为相同的参数名常在服务器配置中用于为可为资源选择的各种表示分配相对质量的权重。

权重被归一化为 0 到 1 范围内的实数，其中 0.001 最不偏好，1 最偏好；值为 0 表示“不可接受”。如果未提供 "q" 参数，则默认权重为 1。

  weight = OWS ";" OWS "q=" qvalue
  qvalue = ( "0" [ "." 0*3DIGIT ] )
         / ( "1" [ "." 0*3("0") ] )

qvalue 的发送方 MUST NOT 生成小数点后超过三位的数字。用户配置这些值时也应受同样限制。

大多数在本处指明的头字段定义了一个选择未指明值的通配值 ("*")。如果未出现通配值，则字段中未明确提到的值被视为不可接受。在 Vary 中，通配值表示变异是无限制的。

"Accept" 头字段可被用户代理用于指定它们关于响应媒体类型的偏好。例如，Accept 头字段可用于指示请求专门限制于一小组期望类型（如对内联图像的请求）。

当服务器在响应中发送时，Accept 提供了有关在对同一资源的后续请求的内容中首选哪些内容类型的信息。

  Accept = #( media-range [ weight ] )

  media-range    = ( "*/*"
                     / ( type "/" "*" )
                     / ( type "/" subtype )
                   ) parameters

星号 "*" 字符用于将媒体类型分组为范围，其中 "*/*" 表示所有媒体类型，"type/*" 表示该 type 的所有子类型。media-range 可以包含适用于该范围的媒体类型参数。

每个 media-range 之后可以跟随可选的适用媒体类型参数（例如 charset），随后可以附带表示相对权重（见 第 12.4.2 节）的可选 "q" 参数。

先前的规范允许在权重参数之后出现额外的扩展参数。accept 扩展语法（accept-params, accept-ext）已被移除，因为其定义复杂、实践中未被使用，并且更容易通过新头字段部署。使用权重的发送方 SHOULD 将 "q" 放在最后（在所有 media-range 参数之后）。接收方 SHOULD 无论参数顺序如何，都将名为 "q" 的参数作为权重处理。

示例

Accept: audio/*; q=0.2, audio/basic

可解释为 “我偏好 audio/basic，但如果在折扣 80% 后它不是最佳可用项，也可发送任何 audio 类型”。

更复杂的例子：

Accept: text/plain; q=0.5, text/html,
       text/x-dvi; q=0.8, text/x-c

口头上，这可以解释为 “text/html 和 text/x-c 同样首选，但如果它们不存在，则发送 text/x-dvi 表示；如果那也不存在，则发送 text/plain 表示”。

媒体范围可以被更具体的媒体范围或具体的媒体类型覆盖。如果多个 media range 适用于给定类型，则最具体的引用具有优先权。例如，

Accept: text/*, text/plain, text/plain;format=flowed, */*

1. text/plain;format=flowed
2. text/plain
3. text/*
4. */*

与给定类型关联的媒体类型质量因子通过找到与类型匹配且具有最高优先级的 media range 来确定。例如，

Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
       text/plain;format=fixed;q=0.4, */*;q=0.5

"Accept-Charset" 头字段可由用户代理发送以指示其对文本响应内容中字符集的偏好。例如，该字段允许能够理解更全面或特殊用途字符集的用户代理向能够以这些字符集表示信息的源服务器声明该能力。

  Accept-Charset = #( ( token / "*" ) [ weight ] )

字符集名称在 第 8.3.2 节 中定义。用户代理 MAY 为每个字符集关联一个质量值以指示用户对该字符集的相对偏好，如 第 12.4.2 节 所定义。例如：

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

特殊值 "*"（如果出现在 Accept-Charset 头字段中）匹配在字段的其他地方未提及的每个字符集。

"Accept-Encoding" 头字段可用于指示关于使用内容编码（参见 第 8.4.1 节）的偏好。

当用户代理在请求中发送时，Accept-Encoding 表示响应中可接受的内容编码。

当服务器在响应中发送时，Accept-Encoding 提供了关于在对同一资源的后续请求的内容中哪些内容编码是首选的信息。

使用 "identity" 作为“无编码”的同义词，以便在偏好中传达何时首选不进行编码。

  Accept-Encoding  = #( codings [ weight ] )
  codings          = content-coding / "identity" / "*"

每个 codings 值 MAY 被赋予一个关联的质量值（权重），表示对该编码的偏好（见 第 12.4.2 节）。Accept-Encoding 字段中的星号 "*" 符号匹配字段中未明确列出的任何可用内容编码。

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

1. 如果请求中没有 Accept-Encoding 头字段，则任何内容编码都被视为用户代理可接受。
2. 如果表示没有内容编码，则默认可接受，除非 Accept-Encoding 头字段明确将其排除，例如列出 "identity;q=0" 或 "*;q=0" 而没有为 "identity" 提供更具体的条目。
3. 如果表示的内容编码列在 Accept-Encoding 字段值中，则可接受，除非其伴随的 qvalue 为 0。（如 第 12.4.2 节 所定义，qvalue 为 0 表示“不可接受”。）

一个表示可以被多个内容编码编码。然而，大多数内容编码是为实现相同目的的替代方式（例如数据压缩）。在选择多个具有相同目的的内容编码之间时，具有最高非零 qvalue 的可接受内容编码优先。

Accept-Encoding 头字段的字段值为空表示用户代理不希望响应中有任何内容编码。如果请求中存在非空的 Accept-Encoding 头字段且可用的响应表示没有列为可接受的内容编码，则源服务器 SHOULD 发送不带任何内容编码的响应，除非 identity 编码被指示为不可接受。

当响应中存在 Accept-Encoding 头字段时，它指示资源在关联请求中愿意接受哪些内容编码。字段值的评估方式与在请求中相同。

注意该信息特定于关联的请求；同一服务器上其他资源可能支持的编码集不同，并可能随时间变化或取决于请求的其他方面（例如请求方法）。

因不支持内容编码而失败请求的服务器应以 415 (Unsupported Media Type) 状态响应，并在该响应中包含 Accept-Encoding 头字段，以便客户端区分与内容编码相关的问题和媒体类型相关的问题。为避免与媒体类型相关问题混淆，对于与内容编码无关而返回 415 的情况，服务器 MUST NOT 包含 Accept-Encoding 头字段。

Accept-Encoding 最常见的用途是在响应因客户端乐观使用内容编码而导致的 415 (Unsupported Media Type) 状态码的响应中。然而，该头字段也可用于指示客户端支持哪些内容编码，以便优化未来的交互。例如，当请求内容足够大以证明使用压缩编码是值得的，但客户端未使用时，资源可能在 2xx (Successful) 响应中包含该字段以告知客户端。

"Accept-Language" 头字段可被用户代理用于指示在响应中首选的一组自然语言。语言标签在 第 8.5.1 节 中定义。

  Accept-Language = #( language-range [ weight ] )
  language-range  =
            <language-range, see [RFC4647], Section 2.1>

每个 language-range 可以被赋予一个关联的质量值，表示用户对该范围指定的语言的偏好估计，如 第 12.4.2 节 所定义。例如：

Accept-Language: da, en-gb;q=0.8, en;q=0.7

表示 “我偏好丹麦语，但也接受英式英语和其他类型的英语”。

注意，有些接收方将语言标签列出的顺序视为优先级递减的指示，特别是对那些被赋予相等质量值的标签（未指定值等同于 q=1）。然而，这种行为不能被依赖。为一致性并最大化互操作性，许多用户代理会为每个语言标签分配唯一的质量值，同时也按降序列出它们。关于语言优先级列表的更多讨论见 RFC4647 第 2.3 节。

对于匹配，RFC4647 第 3 节 定义了几种匹配方案。实现可以根据其需求提供最合适的匹配方案。“基本过滤”方案（见 RFC4647 第 3.3.1 节）与以前在 HTTP 中为此定义的匹配方案相同（见 RFC2616 第 14.4 节）。

在每个请求中发送完整的用户语言偏好可能违背用户的隐私期望（参见 第 17.13 节）。

由于可理解性高度依赖于个别用户，用户代理需要允许用户对语言偏好进行控制（通过用户代理自身的配置或默认采用可由用户控制的系统设置）。未向用户提供此类控制的用户代理 MUST NOT 发送 Accept-Language 头字段。

响应中的 "Vary" 头字段描述了请求消息的哪些部分（除了方法和目标 URI 之外）可能影响了源服务器选择此响应内容的过程。

  Vary = #( "*" / field-name )

Vary 字段值要么为通配成员 "*"，要么为一列请求字段名，称为选择性头字段，这些字段可能在为该响应选择表示时起了作用。潜在的选择性头字段不局限于本规范定义的字段。

包含成员 "*" 的列表表示请求的其他方面可能在选择响应表示时起了作用，可能包括消息语法之外的方面（例如客户端的网络地址）。接收方将无法确定该响应是否适用于以后的请求，而不将请求转发给源服务器。代理 MUST NOT 在 Vary 字段值中生成 "*"。

例如，包含下列内容的响应

Vary: accept-encoding, accept-language

表示源服务器在选择该响应内容时可能使用了请求的 Accept-Encoding 和 Accept-Language 头字段（或它们的缺失）作为决定性因素。

1. 告知缓存接收方，除非后来的请求在所列头字段上与原始请求具有相同的值，或者该响应的重用已被源服务器验证，否则它们 MUST NOT 使用该响应来满足后续的请求（参见 CACHING 第 4.1 节）。换言之，Vary 扩展了匹配新请求与存储缓存条目的所需缓存键。

2. 告知用户代理接收方该响应受内容协商（第 12 节）影响，并且如果在所列头字段中提供了其他值，则后续请求可能会发送不同的表示（即 主动协商）。

当源服务器希望该可缓存响应在后续请求中被有选择地重用时，源服务器 SHOULD 在可缓存响应上生成 Vary 头字段。通常，当响应内容已根据所选头字段表达的偏好进行定制时（例如源服务器根据请求的 Accept-Language 头字段选择响应的语言），就应如此。

当源服务器认为内容选择中的变化性对缓存的性能影响小于 Vary 所带来的影响时，特别是在重用已经受缓存响应指令限制的情况下，Vary 可以被省略（参见 CACHING 第 5.2 节）。

没有必要在 Vary 中发送 Authorization 字段名，因为根据该字段定义，不允许将该响应重用于不同的用户（参见 第 11.6.2 节）。同样，如果响应内容的选择或影响是由网络区域决定的，但源服务器希望即使接收方从一个区域移动到另一个区域也能重用缓存响应，则没有必要在 Vary 中指示此类变异。

“If-Match” 头字段使请求方法以接收方源服务器：当字段值为 "*" 时拥有目标资源的至少一个当前表示，或者拥有一个其实体标签与字段值中提供的实体标签列表中某一成员匹配的当前表示为条件。

在比较 If-Match 的实体标签时，源服务器 MUST 使用强比较函数（参见 第 8.8.3.2 节），因为客户端的意图是当表示数据有任何变化时阻止方法的应用。

  If-Match = "*" / #entity-tag

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

If-Match 最常与会改变状态的方法（例如 POST、PUT、DELETE）一起使用，以在多个用户代理可能并行操作同一资源时防止意外覆盖（即防止“丢失更新”问题）。总体而言，任何涉及选择或修改表示的方法都可以使用它来在所选表示的当前实体标签不在 If-Match 字段值中时中止请求。

当源服务器接收到选择某表示且该请求包含 If-Match 头字段的请求时，源服务器 MUST 在执行该方法之前按照 第 13.2 节 评估 If-Match 条件。

1. 如果字段值为 "*"，当源服务器对目标资源有当前表示时条件为真。
2. 如果字段值为实体标签列表，当所列任一标签与所选表示的实体标签匹配时条件为真。
3. 否则，条件为假。

当 If-Match 条件评估为 false 时，源服务器 MUST NOT 执行请求的方法。相反，源服务器 MAY 通过响应 412 (Precondition Failed) 状态码来表明条件请求失败。或者，如果该请求是一个看起来已经对所选表示生效的状态改变操作，源服务器 MAY 响应一个 2xx (Successful) 状态码（即用户代理请求的变更实际上已经成功，但用户代理可能未意识到，例如因为先前的响应丢失或其他用户代理做了等效的更改）。

当允许源服务器在看似已应用变更的情况下发送成功响应时，这对许多创作类用例更高效，但如果多个用户代理进行非常相似但不协作的变更请求，则存在风险。例如，多个用户代理将共同资源用作信号量（例如 nonatomic increment）可能会冲突并导致重要状态转变丢失。对于此类资源，源服务器最好在对不安全方法的每个失败前置条件都严格返回 412。在其他情况下，从成功响应中排除 ETag 字段可能会促使用户代理随后执行 GET 以消除对资源当前状态的混淆。

客户端 MAY 在 GET 请求中发送 If-Match 头字段以表明若所选表示不匹配则更希望收到 412 (Precondition Failed) 响应。然而，这仅在范围请求（参见 第 14 节）中对完成先前接收的部分表示有用，而不希望得到新的表示。对于在客户端更愿意接收新表示的范围请求，If-Range（见 第 13.1.5 节）更为合适。

缓存或中间件 MAY 忽略 If-Match，因为其互操作性特性仅对源服务器是必要的。

注意，If-Match 头字段如果其列表值同时包含 "*" 与其他值（包括其他 "*" 实例）是语法上无效的（因此不允许生成），并且很可能不可互操作。

“If-None-Match” 头字段使请求方法以接收方缓存或源服务器：当字段值为 "*" 时不拥有目标资源的任何当前表示，或者所选表示的实体标签不匹配字段值中列出的任一标签为条件。

接收方 MUST 在比较 If-None-Match 的实体标签时使用弱比较函数（参见 第 8.8.3.2 节），因为即使表示数据发生了变化，弱实体标签也可用于缓存验证。

  If-None-Match = "*" / #entity-tag

If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *

If-None-Match 主要用于条件 GET 请求，以尽量减少事务开销地实现缓存信息的高效更新。当客户端希望更新一个或多个具有实体标签的已存储响应时，客户端 SHOULD 在发出 GET 请求时生成包含那些实体标签列表的 If-None-Match 头字段；这允许接收方服务器在所列的某一已存储响应与所选表示匹配时返回 304 (Not Modified) 响应来指示匹配。

If-None-Match 也可与 "*" 值一起使用，以阻止不安全的请求方法（例如 PUT）在客户端认为资源没有当前表示时无意中修改目标资源的已有表示。这是“丢失更新”问题的一种变体，可能在多个客户端尝试为目标资源创建初始表示时出现。

当源服务器接收到选择某表示且该请求包含 If-None-Match 头字段的请求时，源服务器 MUST 在执行该方法之前按照 第 13.2 节 评估 If-None-Match 条件。

1. 如果字段值为 "*"，当源服务器对目标资源有当前表示时条件为假。
2. 如果字段值为实体标签列表，当所列任一标签与所选表示的实体标签匹配时条件为假。
3. 否则，条件为真。

当 If-None-Match 条件评估为 false 时，源服务器 MUST NOT 执行请求的方法；相反，源服务器 MUST 返回：a) 如果请求方法为 GET 或 HEAD，则返回 304 (Not Modified)，或 b) 对于其他方法，则返回 412 (Precondition Failed)。

关于接收到的 If-None-Match 头字段的缓存处理要求，定义见 CACHING 第 4.3.2 节（参见 [CACHING]）。

注意，If-None-Match 头字段如果其列表值同时包含 "*" 与其他值（包括其他 "*" 实例）是语法上无效的（因此不允许生成），并且很可能不可互操作。

“If-Modified-Since” 头字段使 GET 或 HEAD 请求方法以所选表示的修改日期晚于字段值所提供的日期为条件。如果数据未改变，则可避免传输所选表示的数据。

  If-Modified-Since = HTTP-date

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

如果请求包含 If-None-Match 头字段，则接收方 MUST 忽略 If-Modified-Since；因为 If-None-Match 中的条件被视为对 If-Modified-Since 条件更精确的替代项，两者仅为与可能不实现 If-None-Match 的旧中间件互操作而组合使用。

如果接收到的 If-Modified-Since 字段值不是有效的 HTTP-date、字段值包含多个成员，或请求方法既不是 GET 也不是 HEAD，则接收方 MUST 忽略该字段。

如果资源没有可用的修改日期，接收方 MUST 忽略 If-Modified-Since 头字段。

接收方 MUST 根据源服务器的时钟来解释 If-Modified-Since 字段值的时间戳。

If-Modified-Since 通常有两个不同的用途：1) 允许高效更新没有实体标签的缓存表示，以及 2) 将 Web 遍历限制在最近更改过的资源范围内。

用于缓存更新时，缓存通常使用缓存消息的 Last-Modified 头字段的值来生成 If-Modified-Since 的字段值。在时钟不同步或服务器仅选择精确时间戳匹配的场景中，这种行为最具互操作性（例如当源服务器的时钟被校正或从归档备份恢复表示时，Last-Modified 似乎“回到过去”）。不过，当缓存的消息不包含 Last-Modified 时，缓存有时也会基于其他数据（例如缓存消息的 Date 头字段或接收消息时的本地时间）生成该字段值。

用于将检索范围限制在最近时间窗口时，用户代理将基于自身时钟或先前从服务器接收的 Date 头字段生成 If-Modified-Since 字段值。选择基于所选表示的 Last-Modified 头字段进行精确时间戳匹配的源服务器将无法帮助用户代理将数据传输限制为仅在指定窗口期间更改的那些内容。

当源服务器接收到选择某表示且该请求包含 If-Modified-Since 头字段但不包含 If-None-Match 头字段时，源服务器 SHOULD 在执行该方法之前按照 第 13.2 节 评估 If-Modified-Since 条件。

1. 如果所选表示的最后修改日期早于或等于字段值提供的日期，则条件为假。
2. 否则，条件为真。

当 If-Modified-Since 条件评估为 false 时，源服务器 SHOULD NOT 执行请求的方法；相反，源服务器 SHOULD 生成一个 304 (Not Modified) 响应，只包含那些对识别或更新先前缓存响应有用的元数据。

关于接收到的 If-Modified-Since 头字段的缓存处理要求见 CACHING 第 4.3.2 节（参见 [CACHING]）。

“If-Unmodified-Since” 头字段使请求方法以所选表示的最后修改日期早于或等于字段值中提供的日期为条件。对于用户代理没有表示的实体标签的情况，该字段实现了与 If-Match 相同的目的。

  If-Unmodified-Since = HTTP-date

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

如果请求同时包含 If-Match 头字段，则接收方 MUST 忽略 If-Unmodified-Since；If-Match 中的条件被视为对 If-Unmodified-Since 的更精确替代，二者仅为与可能不实现 If-Match 的旧中间件互操作而组合使用。

如果接收到的 If-Unmodified-Since 字段值不是有效的 HTTP-date（包括字段值看起来像一个日期列表的情况），接收方 MUST 忽略该字段。

如果资源没有可用的修改日期，接收方 MUST 忽略 If-Unmodified-Since 字段。

接收方 MUST 根据源服务器的时钟来解释 If-Unmodified-Since 字段值的时间戳。

If-Unmodified-Since 最常与会改变状态的方法（例如 POST、PUT、DELETE）一起使用，以在多个用户代理可能并行操作且表示没有提供实体标签时防止意外覆盖（即防止“丢失更新”问题）。总体而言，任何涉及选择或修改表示的方法都可以使用它来在所选表示的最后修改日期自字段值以来已改变时中止请求。

当源服务器接收到选择某表示且该请求包含 If-Unmodified-Since 头字段但不包含 If-Match 头字段时，源服务器 MUST 在执行该方法之前按照 第 13.2 节 评估 If-Unmodified-Since 条件。

1. 如果所选表示的最后修改日期早于或等于字段值提供的日期，则条件为真。
2. 否则，条件为假。

当 If-Unmodified-Since 条件评估为 false 时，源服务器 MUST NOT 执行请求的方法。相反，源服务器 MAY 通过响应 412 (Precondition Failed) 状态码来表明条件请求失败。或者，如果请求是看起来已经对所选表示生效的状态改变操作，源服务器 MAY 响应一个 2xx (Successful) 状态码（即请求的变更已经成功，但用户代理可能不知道）。

在某些创作类用例中，当变更请求似乎已被应用时允许源服务器返回成功响应会更高效，但当多个用户代理发出非常相似但不协作的变更请求时，这会带来风险。在那些情况下，源服务器最好在对不安全方法的每个失败前置条件都严格返回 412。

客户端 MAY 在 GET 请求中发送 If-Unmodified-Since 头字段以表明若所选表示已被修改则更愿意收到 412 (Precondition Failed) 响应。然而，这仅在范围请求（参见 第 14 节）中对完成先前接收的部分表示有用。对于在客户端更愿意接收新表示的范围请求，If-Range（见 第 13.1.5 节）更为合适。

缓存或中间件 MAY 忽略 If-Unmodified-Since，因为其互操作性特性仅对源服务器必要。

“If-Range” 头字段提供了一种特殊的条件请求机制，类似于 If-Match 和 If-Unmodified-Since，但其指示接收方在验证器不匹配时忽略 Range 头字段，从而在验证器不匹配时传输新的 selected representation，而不是返回 412 (Precondition Failed)。

如果客户端持有某个表示的部分副本并希望获得该表示的最新版完整副本，它可以在条件 GET 中使用 Range 头字段（并使用 If-Unmodified-Since 和/或 If-Match 作为前置条件）。但是，如果前置条件因为表示已被修改而失败，客户端则需要发起第二次请求以获取完整的当前表示。

“If-Range” 头字段允许客户端“短路”第二次请求。非正式地，其含义为：如果表示未改变，则发送我请求的 Range 部分；否则，发送整个表示。

  If-Range = entity-tag / HTTP-date

通过检查前三个字符是否为 DQUOTE，可以将有效的 entity-tag 与有效的 HTTP-date 区分开来。

客户端 MUST NOT 在不包含 Range 头字段的请求中生成 If-Range。服务器在接收到不包含 Range 的请求中 If-Range 时 MUST 忽略该 If-Range。对于不支持 Range 请求的目标资源，源服务器在接收到 If-Range 时 MUST 忽略该字段。

客户端 MUST NOT 生成包含标记为弱的实体标签的 If-Range 头字段。除非客户端对相应表示没有实体标签，且该日期在 第 8.8.2.2 节 中定义意义上是一个强验证器，否则客户端 MUST NOT 生成包含 HTTP-date 的 If-Range。

在 Range 请求上接收到 If-Range 头字段的服务器 MUST 在执行方法之前按照 第 13.2 节 评估该条件。

1. 如果所提供的 HTTP-date 验证器不是在 第 8.8.2.2 节 中定义意义上的强验证器，则该条件为假。
2. 如果所提供的 HTTP-date 验证器与所选表示的 Last-Modified 字段值完全匹配，则该条件为真。
3. 否则，该条件为假。

1. 如果提供的 entity-tag 验证器使用强比较函数（参见 第 8.8.3.2 节）与所选表示的 ETag 字段值完全匹配，则条件为真。
2. 否则，条件为假。

If-Range 的接收者 MUST 在 If-Range 条件评估为假时忽略 Range 头字段。否则，接收者 SHOULD 按请求处理 Range 头字段。

注意 If-Range 比较是按精确匹配进行的，包括当验证器为 HTTP-date 时，因此它不同于在评估 If-Unmodified-Since 条件时使用的“早于或等于”比较。

除下文排除的情况外，接收方缓存或源服务器 MUST 在成功完成其正常请求检查并且就在处理请求内容（如果有）或执行与请求方法相关联的动作之前评估收到的请求前置条件。如果在在处理请求内容之前对同一请求不带这些条件的响应将是除 2xx (Successful) 或 412 (Precondition Failed) 之外的状态码，则服务器 MUST 忽略所有收到的前置条件。换言之，可以在大量处理发生之前检测到的重定向和失败优先于前置条件的评估。

如果一个服务器不是目标资源的源服务器并且不能作为目标资源请求的缓存，它 MUST NOT 评估本规范定义的条件请求头字段，并且在转发请求时 MUST 转发这些字段，因为生成这些字段的客户端希望它们由能够提供当前表示的服务器来评估。同样，当收到的请求方法不涉及所选表示的选择或修改（例如 CONNECT、OPTIONS 或 TRACE）时，服务器 MUST 忽略本规范定义的条件请求头字段。

注意，协议扩展可以修改评估前置条件的条件或评估它们的后果。例如，不可变缓存指令（由 [RFC8246] 定义）指示缓存在持有新鲜响应时放弃转发条件请求。

尽管条件请求头字段被定义为可与 HEAD 方法一起使用（以使 HEAD 的语义与 GET 保持一致），但发送条件 HEAD 毫无意义，因为成功响应的大小与 304 (Not Modified) 响应相近，而后者比 412 (Precondition Failed) 更有用。

当请求中存在多个条件请求头字段时，字段的评估顺序就变得重要。实际上，本文档中定义的字段在实现中通常按一个统一的逻辑顺序实现，因为“丢失更新”前置条件的要求比缓存验证更严格，经过验证的缓存比部分响应更高效，并且实体标签被认为比日期验证器更准确。

1. 当接收方为源服务器且存在 If-Match 时，评估 If-Match 前置条件：

   • 若为真，则继续执行第 3
   • 若为假，则响应 412 (Precondition Failed)，除非可以确定该会改变状态的请求已被执行成功（参见 第 13.1.1 节）

2. 当接收方为源服务器，且不存在 If-Match，但存在 If-Unmodified-Since 时，评估 If-Unmodified-Since 前置条件：

   • 若为真，则继续执行第 3
   • 若为假，则响应 412 (Precondition Failed)，除非可以确定该会改变状态的请求已被执行成功（参见 第 13.1.4 节）

3. 当存在 If-None-Match 时，评估 If-None-Match 前置条件：

   • 若为真，则继续执行第 5
   • 若对 GET/HEAD 为假，则响应 304 (Not Modified)
   • 若对其他方法为假，则响应 412 (Precondition Failed)

4. 当方法为 GET 或 HEAD，且不存在 If-None-Match，但存在 If-Modified-Since 时，评估 If-Modified-Since 前置条件：

   • 若为真，则继续执行第 5
   • 若为假，则响应 304 (Not Modified)

5. 当方法为 GET 且同时存在 Range 与 If-Range 时，评估 If-Range 前置条件：

   • 若为真且 Range 适用于所选表示，则响应 206 (Partial Content)
   • 否则，忽略 Range 头字段并响应 200 (OK)

6. 否则，

   • 执行请求的方法并根据其成功或失败作出响应。

任何对 HTTP 的扩展如果定义了额外的条件请求头字段，应当定义这些字段相对于本文档中定义的字段以及实践中可能出现的其他条件的评估顺序。

范围通过范围单位与一组范围说明符配对来表示。范围单位名称决定哪些类型的 range-spec 适用于其自身的说明符。因此，下面的语法是通用的：每个范围单位应规定何时允许 int-range、suffix-range 和 other-range。

一个范围请求可以在单个表示内指定单个范围或一组范围。

  ranges-specifier = range-unit "=" range-set
  range-set        = 1#range-spec
  range-spec       = int-range
                   / suffix-range
                   / other-range

int-range 是以两个非负整数表示的范围，或以一个非负整数表示直到表示数据末尾的范围。范围单位指定这些整数的含义（例如，它们可能表示从开头的单元偏移量、包括端点的编号部分等）。

  int-range     = first-pos "-" [ last-pos ]
  first-pos     = 1*DIGIT
  last-pos      = 1*DIGIT

如果存在 last-pos 且其值小于 first-pos，则该 int-range 是无效的。

suffix-range 是以表示数据的后缀表示的范围，给出的是所提供的非负整数最大长度（以范围单位为单位）。换言之，即表示数据的最后 N 个单元。

  suffix-range  = "-" suffix-length
  suffix-length = 1*DIGIT

为支持可扩展性，other-range 规则为几乎不受约束的语法，允许特定应用或未来的范围单位定义额外的范围说明符。

  other-range   = 1*( %x21-2B / %x2D-7E )
                ; 1*(VCHAR excluding comma)

如果 ranges-specifier 包含任何对所指示的 range-unit 来说无效或未定义的 range-spec，则该 ranges-specifier 是无效的。

如果一个有效的 ranges-specifier 包含至少一个相对于所指示的 range-unit 而言是可满足的 range-spec，则称其为 satisfiable；否则称为 unsatisfiable。

“bytes” 范围单位用于表示表示数据的 octet（字节）序列的子范围。每个字节范围表示为相对于表示数据的开头（int-range）或结尾（suffix-range）的整数范围。字节范围不使用 other-range 说明符。

在 bytes 的 int-range 中，first-pos 值表示范围中第一个字节的偏移。last-pos 值表示范围中最后一个字节的偏移；也就是说，所指定的字节位置是包含端点的。字节偏移从零开始。

如果对表示数据应用了内容编码，则每个字节范围相对于编码后的字节序列计算，而不是解码后得到的底层字节序列。

• 前 500 个字节（字节偏移 0-499，包含端点）：

  bytes=0-499
  

• 第二个 500 个字节（字节偏移 500-999，包含端点）：

  bytes=500-999
  

客户端可以在不知道所选表示大小的情况下限制请求的字节数。如果 last-pos 值缺失，或该值大于或等于表示数据的当前长度，则该字节范围被解释为表示的剩余部分（即服务器将 last-pos 的值替换为所选表示当前长度减一）。

客户端可以使用 suffix-range 引用所选表示的最后 N 个字节（N > 0）。如果所选表示短于指定的 suffix-length，则使用整个表示。

• 最后 500 个字节（字节偏移 9500-9999，包含端点）：

  bytes=-500
  

  或：

  bytes=9500-
  

• 仅第一个和最后一个字节（字节 0 和 9999）：

  bytes=0-0,-1
  

• 第一个、中间和最后各 1000 个字节：

  bytes= 0-999, 4500-5499, -1000
  

• 第二个 500 个字节（字节偏移 500-999，包含端点）的其他有效（但非规范）说明：

  bytes=500-600,601-999
  bytes=500-700,601-999
  

• 为具有 first-pos 小于所选表示当前长度的 int-range；或
• 为具有非零 suffix-length 的 suffix-range。

当所选表示长度为零时，在 GET 请求中唯一可满足的 range-spec 形式是带有非零 suffix-length 的 suffix-range。

在字节范围语法中，first-pos、last-pos 与 suffix-length 以十进制表示为八位字节数。由于内容长度没有预定义上限，接收方 MUST 预期可能出现很大的十进制数，并防止因整数转换溢出导致的解析错误。

100 (Continue) 状态码表示请求的初始部分已被接收且尚未被服务器拒绝。服务器打算在完全接收并处理完请求后发送最终响应。

当请求包含一个带有 100-continue 期望的 Expect 头字段时，100 响应表示服务器希望接收请求内容，如 第 10.1.1 节 所述。客户端应继续发送请求并丢弃该 100 响应。

如果请求不包含带有 100-continue 期望的 Expect 头字段，客户端可以简单地丢弃此临时响应。

101 (Switching Protocols) 状态码表示服务器理解并愿意遵从客户端通过 Upgrade 头字段（见 第 7.8 节）发起的用于更改此连接上使用的应用协议的请求。服务器 MUST 在响应中生成一个 Upgrade 头字段，指明在此响应之后将生效的协议。

通常假定服务器仅在切换协议有利时才同意这样做。例如，切换到更新的 HTTP 版本可能优于旧版本；在交付使用实时、同步特性的资源时，切换到实时同步协议可能更有利。

除 CONNECT 的响应外，除非消息分块明确指示内容长度为零，否则 200 响应预计包含消息内容。如果请求的某些方面表示成功时希望没有内容，源服务器应发送 204 (No Content) 响应。对于 CONNECT，没有内容因为成功结果是一个隧道，它在 200 响应头部部分之后立即开始。

200 响应是启发式可缓存的；即除非方法定义或显式缓存控制另有指示（参见 CACHING 第 4.2.2 节）。

对于对 GET 或 HEAD 的 200 响应，源服务器 SHOULD 为所选表示发送任何可用的验证器字段（见 第 8.8 节），首选同时提供强实体标签和 Last-Modified 日期。

对于对会改变状态的方法的 200 响应，任何在响应中发送的验证器字段（见 第 8.8 节）传达的是成功应用请求语义后新生成表示的当前验证器。注意 PUT 方法（参见 第 9.3.4 节）具有可能阻止发送此类验证器的附加要求。

201 (Created) 状态码表示请求已被实现并导致一个或多个新资源被创建。由请求创建的主要资源通过响应中的 Location 头字段标识，或者如果没有收到 Location 头字段，则由目标 URI 标识。

201 响应的内容通常描述并链接到所创建的资源。任何在响应中发送的验证器字段（见 第 8.8 节）传达的是由请求创建的新表示的当前验证器。注意 PUT 方法（参见 第 9.3.4 节）具有可能阻止发送此类验证器的附加要求。

202 (Accepted) 状态码表示请求已被接受以供处理，但处理尚未完成。请求可能最终会被处理，也可能不会被处理，因为在实际处理时可能被拒绝。HTTP 中没有用于从异步操作重新发送状态码的机制。

202 响应故意保持非承诺性。其目的是允许服务器接受某个供其他进程（也许是每天仅运行一次的批处理）处理的请求，而不要求用户代理与服务器的连接持续到处理完成。随该响应发送的表示应描述请求的当前状态并指向（或嵌入）一个状态监视器，以便为用户提供关于请求何时完成的估计。

203 (Non-Authoritative Information) 状态码表示请求成功，但所封装的内容已被某个转换代理修改，且与源服务器的 200 (OK) 响应不同（参见 第 7.7 节）。当代理对内容应用了转换时，此状态码允许代理通知接收方，这一事实可能会影响针对该内容的后续决策，例如将来对该内容的缓存验证可能仅适用于通过相同请求链路（通过相同代理）。

203 响应是启发式可缓存的；即除非方法定义或显式缓存控制另有指示（参见 CACHING 第 4.2.2 节）。

204 (No Content) 状态码表示服务器已成功完成请求且没有要在响应内容中再发送的额外内容。响应头字段中的元数据指的是在请求动作被应用后目标资源及其所选表示（如果有的话）。

例如，如果对 PUT 请求收到 204 状态码并且响应包含一个 ETag 字段，则说明 PUT 成功，且 ETag 字段值包含该目标资源新表示的实体标签。

204 响应允许服务器表示该动作已成功应用于目标资源，同时暗示用户代理无需离开其当前的“文档视图”（如果有的话）。服务器假定用户代理会根据其界面向用户提供某种成功提示，并将响应中新的或更新的元数据应用于其活动表示。

例如，在与“保存”操作对应的文档编辑界面中通常使用 204 状态码，以便被保存的文档仍然可供用户编辑。它也常用于期望自动化数据传输普遍存在的接口，例如分布式版本控制系统中。

204 响应以头部部分结束；它不能包含内容或尾部字段。

204 响应是启发式可缓存的；即除非方法定义或显式缓存控制另有指示（参见 CACHING 第 4.2.2 节）。

205 (Reset Content) 状态码表示服务器已完成请求，并希望用户代理重置导致该请求被发送的“文档视图”，将其恢复为从源服务器接收时的原始状态。

此响应旨在支持常见的数据录入用例：用户收到支持数据录入的内容（表单、记事本、画布等），在该空间输入或操作数据，提交这些数据形成请求，然后数据录入机制被重置以供下一次输入，从而便于用户再次发起输入操作。

由于 205 状态码意味着不会提供额外内容，服务器 MUST NOT 在 205 响应中生成内容。

206 (Partial Content) 状态码表示服务器成功地满足了对目标资源的范围请求，通过传输所选表示的一个或多个部分来完成。

支持范围请求（见 第 14 节）的服务器通常会尝试满足所有请求的范围，因为发送更少的数据可能会导致客户端为剩余内容发起另一个请求。然而，服务器可能出于自身原因（例如临时不可用、缓存效率、负载平衡等）只发送请求数据的一个子集。由于 206 响应是自描述的，客户端仍然可以理解仅部分满足范围请求的响应。

客户端 MUST 检查 206 响应的 Content-Type 和 Content-Range 字段以确定包含了哪些部分以及是否需要额外的请求。

生成 206 响应的服务器 MUST 生成下列头字段（如果在对相同请求的 200 (OK) 响应中会发送它们），除非在下文小节中另有规定：Date、Cache-Control、ETag、Expires、Content-Location 和 Vary。

在 206 响应中出现的 Content-Length 头字段表示该消息内容的八位字节数，通常不是所选表示的完整长度。每个 Content-Range 头字段包含有关所选表示完整长度的信息。

对带有 If-Range 头字段的请求生成 206 响应的发送方 SHOULD NOT 生成额外的表示头字段，因为客户端已经持有先前响应中包含的这些头字段。否则，发送方 MUST 生成在对相同请求的 200 (OK) 响应中本应发送的所有表示头字段。

206 响应是启发式可缓存的；即除非显式缓存控制另有指示（参见 CACHING 第 4.2.2 节）。

300 (Multiple Choices) 状态码表示目标资源具有多个表示，每个表示都有各自更具体的标识符，并且服务器提供了有关这些替代项的信息，以便用户（或用户代理）可以通过将其请求重定向到这些标识符之一或多个来选择首选表示。换言之，服务器希望用户代理进行被动协商以选择最适合其需求的表示（参见 第 12 节）。

如果服务器有首选的选择，服务器 SHOULD 在响应中生成一个包含首选选择 URI 引用的 Location 头字段。用户代理 MAY 使用 Location 字段值进行自动重定向。

对于除 HEAD 之外的方法，服务器 SHOULD 在 300 响应中生成包含一系列表示元数据和 URI 引用的内容，以便用户或用户代理可以从中选择最合适的。用户代理 MAY 如果能理解所提供的媒体类型而自动从该列表中选择。由于 HTTP 力求与内容定义保持正交，本规范并未定义用于自动选择的具体格式。实际上，表示通常以某种认为对用户代理可接受的易解析格式提供，或以某些常用的超文本格式提供，具体由共享设计或内容协商决定。

300 响应是启发式可缓存的；即除非方法定义或显式缓存控制另有指示（参见 CACHING 第 4.2.2 节）。

301 (Moved Permanently) 状态码表示目标资源已被分配了一个新的永久 URI，今后对该资源的任何引用都应使用响应中包含的某个 URI。服务器建议具有链接编辑能力的用户代理可以永久替换对目标 URI 的引用为服务器发送的新引用之一。然而，除非用户代理正在主动编辑引用（例如进行内容创作）、连接已加密并且源服务器是所编辑内容的可信权威，否则通常会忽略此建议。

服务器 SHOULD 在响应中生成包含首选新永久 URI 的 Location 头字段。用户代理 MAY 使用 Location 字段值进行自动重定向。服务器的响应内容通常包含一个指向新 URI 的简短超文本说明。

301 响应是启发式可缓存的；即除非方法定义或显式缓存控制另有指示（参见 CACHING 第 4.2.2 节）。

302 (Found) 状态码表示目标资源临时位于不同的 URI 下。由于重定向可能会偶尔改变，客户端应继续在未来请求中使用目标 URI。

服务器 SHOULD 在响应中生成包含不同 URI 的 Location 头字段。用户代理 MAY 使用 Location 字段值进行自动重定向。服务器的响应内容通常包含一个指向不同 URI 的简短超文本说明。

303 (See Other) 状态码表示服务器将用户代理重定向到另一个资源（由 Location 头字段指示），该资源意在作为对原始请求的间接响应。用户代理可以对该 URI 发起检索请求（如果使用 HTTP，则为 GET 或 HEAD），该请求可能也会被重定向，并最终将结果作为对原始请求的响应呈现。注意 Location 头字段中的新 URI 并不被视为与目标 URI 等价。

该状态码适用于任何 HTTP 方法。它主要用于允许 POST 操作的输出重定向用户代理到不同资源，因为这可以将 POST 响应对应的信息作为一个可单独识别、可书签和可缓存的资源提供。

对 GET 请求的 303 响应表示源服务器没有可以通过 HTTP 传输的目标资源的表示。然而，Location 字段值引用的资源是描述目标资源的资源，因此对该其他资源发起检索请求可能会得到对接收方有用的表示，而不意味着它代表原始目标资源。关于什么可以被表示、哪些表示是充分的以及什么可能是有用的描述不在 HTTP 的范畴内。

除对 HEAD 请求的响应外，303 响应的表示应包含一个指向 Location 头字段中同一 URI 的简短超文本说明。

304 (Not Modified) 状态码表示已收到带条件的 GET 或 HEAD 请求，且如果不是因为条件为假，该请求本来会产生 200 (OK) 响应。换言之，服务器无需传输目标资源的表示，因为发起请求的客户端已经持有有效的表示；因此服务器指示客户端使用其已存的表示，仿佛它是 200 (OK) 响应的内容。

• Content-Location、Date、ETag 和 Vary
• Cache-Control 和 Expires（参见 [CACHING]）

由于 304 响应的目标是当接收方已有一个或多个缓存表示时最小化信息传输，发送方 SHOULD NOT 生成除上述字段之外的表示元数据，除非该元数据用于指导缓存更新（例如，如果响应没有 ETag 字段，则 Last-Modified 可能有用）。

接收 304 响应的缓存的要求定义见 CACHING 第 4.3.4 节。如果条件请求源自一个外向客户端（例如具有自己缓存并向共享代理发送条件 GET 的用户代理），则代理 SHOULD 将 304 响应转发给该客户端。

304 响应以头部部分结束；它不能包含内容或尾部字段。

305 (Use Proxy) 状态码在先前版本的规范中定义，现在已不推荐使用（见旧 RFC 附录）。

306 状态码在先前版本的规范中定义，现在不再使用，该代码被保留。

307 (Temporary Redirect) 状态码表示目标资源临时位于不同的 URI 下，并且用户代理在自动重定向到该 URI 时 MUST NOT 更改请求方法。由于重定向可能随时间改变，客户端应继续在未来请求中使用原始目标 URI。

服务器 SHOULD 在响应中生成包含不同 URI 的 Location 头字段。用户代理 MAY 使用 Location 字段值进行自动重定向。服务器的响应内容通常包含一个指向不同 URI 的简短超文本说明。

308 (Permanent Redirect) 状态码表示目标资源已被分配了一个新的永久 URI，今后对该资源的任何引用都应使用响应中包含的某个 URI。服务器建议具有链接编辑能力的用户代理可以永久替换对目标 URI 的引用为服务器发送的新引用之一。然而，除非用户代理正在主动编辑引用、连接已加密且源服务器为可信权威，否则通常会忽略此建议。

服务器 SHOULD 在响应中生成包含首选新永久 URI 的 Location 头字段。用户代理 MAY 使用 Location 字段值进行自动重定向。服务器的响应内容通常包含一个指向新 URI 的简短超文本说明。

308 响应是启发式可缓存的；即除非方法定义或显式缓存控制另有指示（参见 CACHING 第 4.2.2 节）。

400 (Bad Request) 状态码表示服务器因为被认为是客户端错误的原因而无法或拒绝处理请求（例如：请求语法错误、无效的消息分界或欺骗性的请求路由）。

401 (Unauthorized) 状态码表示请求未被应用，因为缺少针对目标资源的有效认证凭证。生成 401 响应的服务器 MUST 在响应中发送至少包含一个适用于目标资源的质询的 WWW-Authenticate 头字段（见 第 11.6.1 节）。

如果请求包含了认证凭证，那么 401 响应表示这些凭证被拒绝。用户代理 MAY 使用新的或替换的 Authorization 头字段重复请求（见 第 11.6.2 节）。如果 401 响应包含与先前响应相同的质询，且用户代理已至少尝试过一次认证，则用户代理 SHOULD 向用户呈现所封装的表示，因为该表示通常包含相关的诊断信息。

402 (Payment Required) 状态码被保留以备将来使用。

403 (Forbidden) 状态码表示服务器理解该请求但拒绝执行它。希望公开说明请求为何被禁止的服务器可以在响应内容（如果有的话）中描述该原因。

如果请求中提供了认证凭证，服务器认为它们不足以授予访问权限。客户端 SHOULD NOT 自动使用相同凭证重复请求。客户端 MAY 使用新的或不同的凭证重复请求。然而，请求被禁止可能与凭证无关。

希望“隐藏”被禁止的目标资源当前存在性的源服务器 MAY 改为以 404 (Not Found) 状态码响应。

404 (Not Found) 状态码表示源服务器未找到目标资源的当前表示或不愿意透露其存在。404 状态码并未指示该缺失是临时还是永久；如果源服务器知道该情况可能是永久的（通过某种可配置手段），则应优先使用 410 (Gone) 状态码。

404 响应是启发式可缓存的；即除非方法定义或显式缓存控制另有指示（参见 CACHING 第 4.2.2 节）。

405 (Method Not Allowed) 状态码表示请求行中收到的方法为源服务器所知道，但目标资源不支持该方法。源服务器 MUST 在 405 响应中生成一个 Allow 头字段，包含目标资源当前支持的方法列表。

405 响应是启发式可缓存的；即除非方法定义或显式缓存控制另有指示（参见 CACHING 第 4.2.2 节）。

406 (Not Acceptable) 状态码表示目标资源没有一个当前表示能被用户代理根据请求中收到的主动协商头字段（见 第 12.1 节）接受，且服务器不愿意提供默认表示。

服务器 SHOULD 生成包含可用表示特性和对应资源标识符列表的内容，供用户或用户代理从中选择最适合的项。用户代理 MAY 从该列表中自动选择最合适的选项。然而，本规范并未定义用于此类自动选择的标准，参见 第 15.4.1 节。

407 (Proxy Authentication Required) 状态码类似于 401 (Unauthorized)，但表示客户端需要进行认证以便使用代理来发起该请求。代理 MUST 发送一个包含适用于该代理的质询的 Proxy-Authenticate 头字段（见 第 11.7.1 节）。客户端 MAY 使用新的或替换的 Proxy-Authorization 头字段重复请求（见 第 11.7.2 节）。

408 (Request Timeout) 状态码表示服务器在其准备等待的时间内未收到完整的请求消息。

如果客户端有未完成的请求在传输中，它 MAY 重复该请求。如果当前连接不可用（例如在 HTTP/1.1 中请求定界丢失），则将使用新的连接。

409 (Conflict) 状态码表示请求由于与目标资源的当前状态存在冲突而无法完成。此代码用于用户可能能够解决冲突并重新提交请求的情形。服务器 SHOULD 生成包含足够信息以便用户识别冲突来源的内容。

冲突最有可能在对 PUT 请求的响应中发生。例如，如果使用了版本控制并且被 PUT 的表示包含与较早（第三方）请求所做更改冲突的更改，则源服务器可能使用 409 来指示无法完成请求。在这种情况下，响应表示可能包含用于根据修订历史合并差异的信息。

410 (Gone) 状态码表示源服务器上已无法再访问目标资源，且此情况可能为永久性。如果源服务器不知道或无法确定该情况是否永久，应使用 404 (Not Found)。

410 响应主要用于通过通知接收方该资源明确不可用并希望移除远程链接来帮助网页维护。这类事件在限时促销服务和不再与源服务器站点关联的个人资源中常见。不必对所有永久不可用的资源都标记为 “gone”，是否以及保持该标记多长时间由服务器所有者自行决定。

410 响应是启发式可缓存的；即除非方法定义或显式缓存控制另有指示（参见 CACHING 第 4.2.2 节）。

411 (Length Required) 状态码表示服务器拒绝接受没有定义 Content-Length 的请求（见 第 8.6 节）。客户端 MAY 在添加了包含请求内容长度的有效 Content-Length 头字段后重复该请求。

412 (Precondition Failed) 状态码表示请求头字段中给定的一个或多个条件在服务器上检测时为假（见 第 13 节）。此响应允许客户端将前置条件施加到当前资源状态（其当前表示和元数据）上，从而在目标资源处于意外状态时阻止请求方法的应用。

413 (Content Too Large) 状态码表示服务器拒绝处理请求，因为请求内容比服务器愿意或能够处理的要大。服务器 MAY 中止请求（如果所用协议版本允许）；否则，服务器 MAY 关闭连接。

如果此情况为临时性的，服务器 SHOULD 生成一个 Retry-After 头字段以指示该情况是临时的以及客户端可以在什么时间后尝试重试。

414 (URI Too Long) 状态码表示服务器拒绝为该请求提供服务，因为目标 URI 比服务器愿意解释的要长。此罕见情形通常发生于客户端将 POST 请求错误地转换为带长查询信息的 GET 请求、客户端陷入重定向的无限循环（例如重定向的 URI 前缀指向其自身的后缀）或服务器遭受企图利用潜在安全漏洞的攻击时。

414 响应是启发式可缓存的；即除非方法定义或显式缓存控制另有指示（参见 CACHING 第 4.2.2 节）。

415 (Unsupported Media Type) 状态码表示源服务器拒绝为该请求提供服务，因为该内容对于目标资源上的此方法而言是未被支持的格式。

格式问题可能由请求指示的 Content-Type 或 Content-Encoding 引起，或由直接检查数据所发现的问题导致。

如果问题由不支持的内容编码引起，则应使用 Accept-Encoding 响应头字段（见 第 12.5.3 节）来指示哪些（如果有）内容编码在请求中会被接受。

另一方面，如果原因是媒体类型不被支持，则可以使用 Accept 响应头字段（见 第 12.5.1 节）来指示哪些媒体类型在请求中会被接受。

416 (Range Not Satisfiable) 状态码表示请求的 Range 头字段中所列范围集已被拒绝，原因要么是没有任何请求的范围是可满足的，要么是客户端请求了过多的小范围或重叠范围（可能构成拒绝服务攻击）。

每个范围单位定义其自身的范围集合要满足的要求。例如，第 14.1.2 节 定义了什么是可满足的字节范围集合。

对字节范围请求生成 416 响应的服务器 SHOULD 生成一个 Content-Range 头字段，指明所选表示的当前长度（见 第 14.4 节）。

HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022

417 (Expectation Failed) 状态码表示请求的 Expect 头字段中给定的期望（见 第 10.1.1 节）至少不能被某一入站服务器满足。

[RFC2324] 是一个愚人节 RFC，讽刺了 HTTP 的各种滥用；其中一次滥用定义了一个应用特定的 418 状态码，作为玩笑被部署得颇多，以致该代码无法用于未来的任何用途。

因此，418 状态码在 IANA HTTP 状态码注册表中被保留。这表示该状态码当前不能分配给其他应用。如果将来需要使用（例如，4NN 状态码耗尽），可以将其重新分配。

421 (Misdirected Request) 状态码表示请求被发送到了一个无法或不愿为目标 URI 产生权威响应的服务器。源服务器（或代表源服务器的网关）发送 421 以拒绝一个与服务器配置的 origin（见 第 4.3.1 节）不匹配或与接收该请求的连接上下文不匹配的目标 URI（见 第 7.4 节）。

收到 421 (Misdirected Request) 响应的客户端 MAY 在不同的连接上重试该请求（无论请求方法是否幂等），例如针对目标资源的 origin 建立一个新的专用连接，或通过替代服务（见 [ALTSVC]）。

代理 MUST NOT 生成 421 响应。

422 (Unprocessable Content) 状态码表示服务器理解请求内容的媒体类型（因此使用 415 (Unsupported Media Type) 不合适），且请求内容的语法是正确的，但无法处理所包含的指令。例如，如果 XML 请求内容是格式正确（即语法无误）但在语义上有错误的 XML 指令，则可以发送此状态码。

426 (Upgrade Required) 状态码表示服务器拒绝使用当前协议执行请求，但在客户端升级到不同协议后可能愿意执行请求。服务器 MUST 在 426 响应中发送一个 Upgrade 头字段以指示所需协议（见 第 7.8 节）。

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

This service requires use of the HTTP/3.0 protocol.

500 (Internal Server Error) 状态码表示服务器遇到了意外情况，导致无法完成请求。

501 (Not Implemented) 状态码表示服务器不支持完成请求所需的功能。当服务器无法识别请求方法且无法为任何资源支持该方法时，应返回此响应。

501 响应是启发式可缓存的；即除非方法定义或显式缓存控制另有指示（参见 CACHING 第 4.2.2 节）。

502 (Bad Gateway) 状态码表示服务器在作为网关或代理时，从其访问的上游服务器收到无效响应，从而无法完成请求。

503 (Service Unavailable) 状态码表示服务器当前由于临时过载或计划内维护而无法处理请求，这种情况可能在一段延迟后得到缓解。服务器 MAY 发送一个 Retry-After 头字段（见 第 10.2.3 节）以建议客户端在重试之前等待的适当时间。

504 (Gateway Timeout) 状态码表示服务器在作为网关或代理时，未能及时从其需要访问以完成请求的上游服务器接收到响应。

505 (HTTP Version Not Supported) 状态码表示服务器不支持或拒绝支持请求消息中使用的 HTTP 主版本。服务器表明它无法或不愿使用与客户端相同的主版本来完成请求，除非以该错误消息形式。服务器 SHOULD 为 505 响应生成一个描述为何该版本不被支持以及该服务器支持哪些其他协议的表示。

“超文本传输协议 (HTTP) 方法注册表”由 IANA 在 https://www.iana.org/assignments/http-methods 维护，用于注册 方法 名称。

• 方法名称（参见 第 9 节）
• 是否为 Safe（“yes” 或 “no”，参见 第 9.2.1 节）
• 是否为 Idempotent（“yes” 或 “no”，参见 第 9.2.2 节）
• 指向规范文本的指针

要添加到此命名空间的值需要进行 IETF 评审（参见 [RFC8126]，第 4.8 节）。

标准化的方法是通用的；也就是说，它们可能适用于任何资源，而不仅限于某一媒体类型、资源种类或应用。因此，建议在非针对单一应用或数据格式的文档中注册新方法，因为正交的技术应由正交的规范来描述。

由于消息解析（见 第 6 节）需要独立于方法语义（HEAD 响应除外），新方法的定义不能更改解析算法或禁止请求或响应消息中存在内容。新方法的定义可以通过要求 Content-Length 头字段值为 "0" 明确限定只允许零长度内容。

同样，新方法不能使用 CONNECT 和 OPTIONS 所允许的特殊 host:port 或星号形式的请求目标（分别参见 CONNECT 与 OPTIONS；见 第 7.1 节）。需要完整形式的 URI 作为目标 URI，这意味着要么以绝对形式发送请求目标，要么像对其他方法那样从请求上下文重构目标 URI。

新方法定义需要指明它是否为 Safe（参见 第 9.2.1 节）、是否为 Idempotent（参见 第 9.2.2 节）、是否可缓存（参见 第 9.2.3 节）、与请求内容（若有）相关的语义，以及方法对头字段或状态码语义所做的任何细化。如果新方法可缓存，其定义应描述缓存如何以及在何种条件下存储响应并用以满足后续请求。新方法应说明是否可被置为有条件请求（参见 第 13.1 节），如果可以，服务器在条件为假时如何响应。同样，如果新方法可能与部分响应语义（见 第 14.2 节）有某种用途，也应在定义中加以说明。

“超文本传输协议 (HTTP) 状态码注册表”由 IANA 在 https://www.iana.org/assignments/http-status-codes 维护，用于注册 状态码 编号。

• 状态码（3 位数字）
• 简短描述
• 指向规范文本的指针

要添加到 HTTP 状态码命名空间的值需要 IETF 评审（参见 [RFC8126]，第 4.8 节）。

当需要表达当前状态码未定义的响应语义时，可以注册新的状态码。状态码是通用的；它们可能适用于任何资源，而不仅限于某一媒体类型、资源种类或 HTTP 的某一应用。因此，建议在非针对单一应用的文档中注册新状态码。

新状态码必须属于第 第 15 节 定义的类别之一。为使现有解析器能够处理响应消息，新状态码不能禁止内容，尽管它们可以强制要求零长度内容。

尚未广泛部署的新状态码提案应避免为代码分配具体数字，直到明确达成注册共识；早期草案可以使用诸如 "4NN" 或 "3N0" .. "3N9" 之类的表示来指示拟议状态码的类别，而不会过早占用编号。

新状态码的定义应解释导致包含该状态码的响应的请求条件（例如，请求头字段组合和/或方法），以及对响应头字段的任何依赖（例如，哪些字段是必需的、哪些字段可以修改语义、以及在与新状态码共同使用时哪些字段语义会被进一步细化）。

默认情况下，状态码仅适用于其所处响应对应的请求。如果某个状态码适用于更大的适用范围——例如，适用于该资源的所有请求或服务器的所有请求——必须明确说明。在这样做时，应注意并非所有客户端都能一致地应用更大范围，因为它们可能并不了解该新状态码。

新最终状态码的定义应指定它是否为启发式可缓存的。注意任何具有最终状态码的响应在具有显式新鲜度信息时都可以被缓存。被定义为启发式可缓存的状态码允许在没有显式新鲜度信息的情况下被缓存。类似地，状态码的定义可以在使用 must-understand 缓存指令时对缓存行为施加约束。有关更多信息，请参阅 [CACHING]。

最后，新状态码的定义应指明该内容是否与某个已识别的资源存在隐含关联（参见 第 6.4.2 节）。

“超文本传输协议 (HTTP) 字段名注册表”定义了 HTTP 字段名的命名空间。

任何一方都可以请求注册 HTTP 字段。创建新 HTTP 字段时应考虑的事项见 第 16.3.2 节。

“超文本传输协议 (HTTP) 字段名注册表”位于 https://www.iana.org/assignments/http-fields/。可以按照该处说明提交注册请求，或发送电子邮件到 "ietf-http-wg@w3.org" 邮件列表。

字段名由指定专家（由 IESG 或其代表任命）在建议下注册。状态为 'permanent' 的字段为 Specification Required（参见 [RFC8126]，第 4.6 节）。

字段名：

请求的字段名。它 MUST 符合在 第 5.1 节 中定义的 field-name 语法，并且 SHOULD 限制为仅使用字母、数字和连字符 ('-') 字符，并以字母为首字符。

状态：

“permanent”、“provisional”、“deprecated” 或 “obsoleted”。

规范文档：

指定该字段的文档引用，最好包含可用于检索文档副本的 URI。对于临时注册可选但鼓励提供。也可包括相关部分的指示，但不是必需的。

注释：

附加信息，例如有关保留条目的说明。

专家可以与社区协商后定义在注册表中需要收集的额外字段。

标准定义的名称具有 "permanent" 状态。如果专家（与社区协商）发现某些其他名称已在使用，也可以将其注册为 permanent。其他名称应注册为 "provisional"。

如果专家（与社区协商）发现临时条目未被使用，专家可以移除该条目。专家可以随时将临时条目的状态更改为 permanent。

注意，如果专家认定某个未注册名称已被广泛部署且否则不太可能及时注册，则该名称可以由第三方（包括专家）注册。

HTTP 头和尾部字段是协议中广泛使用的扩展点。尽管它们可以以临时方式使用，但打算广泛使用的字段需要被仔细记录以确保互操作性。

• 该字段可以在何种条件下使用；例如仅在响应或请求中、在所有消息中、仅在对特定请求方法的响应中等。
• 字段语义是否由其上下文进一步细化，例如与某些请求方法或状态码共同使用时。
• 所传达信息的适用范围。默认情况下，字段仅适用于其所关联的消息，但一些响应字段被设计为适用于资源的所有表示、资源本身或更广泛的范围。扩展响应字段适用范围的规范需要仔细考虑内容协商、适用时间范围以及（在某些情况下）多租户服务器部署等问题。
• 在何种条件下中间件被允许插入、删除或修改该字段的值。
• 该字段是否允许出现在 trailers 中；默认情况下不允许（见 第 6.5.1 节）。
• 该字段名是否应列在 Connection 头字段中（即该字段是否为 hop-by-hop；见 第 7.6.1 节）。
• 该字段是否引入任何额外的安全考虑，例如披露与隐私相关的数据。

• 是否适合在响应的 Vary 头字段中列出该字段名（例如，当该请求头字段被源服务器的内容选择算法使用时；见 第 12.5.5 节）。
• 当在 PUT 请求中接收到该字段时是否应将其存储（见 第 9.3.4 节）。
• 在因安全考虑而自动重定向请求时是否应移除该字段（见 第 15.4 节）。

“超文本传输协议 (HTTP) 认证方案注册表”定义了用于质询和凭证中的认证方案命名空间。该注册表维护在 https://www.iana.org/assignments/http-authschemes。

• 认证方案名称
• 指向规范文本的指针
• 注释（可选）

要添加到此命名空间的值需要 IETF 评审（参见 [RFC8126]，第 4.8 节）。

• HTTP 认证假定为无状态：用于认证请求的所有信息 MUST 在请求中提供，而不应依赖服务器记住先前请求。基于或绑定到底层连接的认证超出本规范范围，除非采取措施确保该连接不能被除已认证用户外的任何一方使用，否则固有上是有缺陷的（参见 第 3.3 节）。

• 认证参数 "realm" 保留用于按照 第 11.5 节 所述定义保护空间。新方案 MUST NOT 以与该定义不兼容的方式使用该参数。

• "token68" 表示法为了与现有认证方案兼容而引入，并且在每个质询或凭证中只能使用一次。因此，新方案应使用 auth-param 语法，否则将来扩展变得不可能。

• 质询和凭证的解析由本规范定义，新认证方案不能修改解析方式。当使用 auth-param 语法时，所有参数应支持 token 和 quoted-string 语法，并且应在解析后（即经过 quoted-string 处理）对字段值定义语法约束。这是必要的，以便接收方可以使用对所有认证方案通用的通用解析器。

  注意：将 "realm" 参数的值语法限制为 quoted-string 是一个不好的设计决策，新参数不应重复此错误。

• 新方案的定义应规定对未知扩展参数的处理。通常，“必须忽略”规则优于“必须理解”规则，因为否则在存在遗留接收方时很难引入新参数。此外，最好描述定义新参数的策略（例如“更新规范”或“使用此注册表”）。

• 认证方案需要说明它们是否可用于源服务器认证（即使用 WWW-Authenticate）和/或代理认证（即使用 Proxy-Authenticate）。

• 在 Authorization 头字段中携带的凭证特定于用户代理，因此在出现该请求的范围内，它们对 HTTP 缓存具有与 "private" 缓存响应指令相同的效果（参见 第 5.2.2.7 节）。

  因此，选择不在 Authorization 头字段中携带凭证（例如使用新定义的头字段）的新认证方案，需要通过强制使用缓存响应指令（例如 "private"）来明确禁止缓存。

• 使用 Authentication-Info、Proxy-Authentication-Info 或任何其他与认证相关的响应头字段的方案，需要考虑并记录相关的安全注意事项（参见 第 17.16.4 节）。

“HTTP 范围单位注册表”定义了范围单位名称的命名空间并指向其相应规范。该注册表维护在 https://www.iana.org/assignments/http-parameters。

• 名称
• 描述
• 指向规范文本的指针

要添加到此命名空间的值需要 IETF 评审（参见 [RFC8126]，第 4.8 节）。

其他范围单位，例如基于格式的边界如页、节、记录、行或时间，可能在 HTTP 中用于特定应用，但在实践中并不常用。替代范围单位的实现者应考虑它们如何与内容编码和通用中间件协同工作。

“HTTP 内容编码注册表”由 IANA 在 https://www.iana.org/assignments/http-parameters/ 维护，用于注册 content-coding 名称。

• 名称
• 描述
• 指向规范文本的指针

内容编码的名称 MUST NOT 与传输编码的名称重叠（参见 “HTTP Transfer Coding Registry” 位于 https://www.iana.org/assignments/http-parameters/），除非编码转换是相同的（例如第 第 8.4.1 节 定义的压缩编码的情形）。

要添加到此命名空间的值需要 IETF 评审（参见 RFC8126 第 4.8 节）并且 MUST 符合在 第 8.4.1 节 中定义的内容编码目的。

新的内容编码应尽可能具有自描述性，其可选参数应可在编码格式内部发现，而不是依赖可能在传输中丢失的外部元数据。

HTTP 认证框架并未定义单一机制来维护凭证的机密性；相反，每个认证方案定义凭证在传输前如何编码。尽管这为未来认证方案的发展提供了灵活性，但对于那些本身不提供机密性或未能充分防护重放攻击的现有方案来说，这不足以保护它们。此外，如果服务器期望凭证是针对每个用户特定的，则传输这些凭证将会导致识别该用户，即使凭证内容保持机密亦然。

HTTP 依赖于底层传输或会话级连接的安全属性来提供字段的机密传输。依赖于个别用户认证的服务在交换凭证之前需要一个 受保护的 连接（第4.2.2节）。

现有的 HTTP 客户端和用户代理通常无限期保留认证信息。HTTP 不提供一种机制让原点服务器指示客户端丢弃这些缓存的凭证，因为协议并不了解凭证是如何被用户代理获取或管理的。凭证过期或撤销的机制可以作为认证方案定义的一部分来指定。

• 已长时间空闲的客户端，之后服务器可能希望使客户端重新提示用户输入凭证。
• 应用包含会话终止指示（例如页面上的“注销”或“提交”按钮），服务器端应用在此之后“知道”客户端没有保留凭证的进一步理由。

缓存凭证的用户代理应提供一种便捷可访问的机制，允许用户在控制下丢弃缓存的凭证。

仅依赖 "realm" 机制来建立保护空间的认证方案会将凭证暴露给原点服务器上的所有资源。成功对某资源进行认证请求的客户端可以对同一原点服务器上的其他资源使用相同的认证凭证。这使得不同资源有可能收集其他资源的认证凭证。

当原点服务器在同一原点下为多个方提供资源时（参见 第11.5节），这尤其令人担忧。可能的缓解策略包括限制直接访问认证凭证（即不使 Authorization 请求首部字段的内容可用）和通过为每一方使用不同的主机名（或端口号）来分隔保护空间。

在未加密通道上向响应中添加信息可能影响安全和隐私。仅存在 Authentication-Info 和 Proxy-Authentication-Info 首部字段就表明 HTTP 认证正在使用。认证方案特定参数的内容可能会暴露额外信息；这需要在这些方案的定义中加以考虑。