14. 头部字段定义 (Header Field Definitions)
14 头部字段定义 (Header Field Definitions)
本节定义所有标准 HTTP/1.1 头部字段的语法和语义. 对于实体头部字段, 发送方和接收方既可以指客户端, 也可以指服务器, 具体取决于谁发送和谁接收该实体.
14.1 Accept
Accept 请求头字段可用于指定响应可接受的媒体类型. Accept 头也可以表示该请求被明确限制在一小组期望类型内, 例如请求内联图像时.
Accept = "Accept" ":"
#( media-range [ accept-params ] )
media-range = ( "*/*"
| ( type "/" "*" )
| ( type "/" subtype )
) *( ";" parameter )
accept-params = ";" "q" "=" qvalue *( accept-extension )
accept-extension = ";" token [ "=" ( token | quoted-string ) ]
星号 "" 用于把媒体类型组合成范围: "/" 表示所有媒体类型, "type/" 表示该类型下的所有子类型. media-range 可以包含适用于该范围的媒体类型参数.
每个 media-range 后面可以跟一个或多个 accept-params, 以表示相对质量因子的 "q" 参数开始. 第一个 "q" 参数用于分隔媒体范围参数和 Accept 扩展参数. 质量因子允许用户或用户代理使用 0 到 1 的 qvalue 标度表示相对偏好. 默认值为 q=1.
注意: 使用 "q" 参数名分隔媒体类型参数和 Accept 扩展参数是历史实践造成的. 虽然这会阻止名为 "q" 的媒体类型参数与媒体范围一起使用, 但鉴于 IANA 媒体类型注册表中没有 "q" 参数, 且 Accept 中很少使用媒体类型参数, 这种情况被认为不太可能发生. 未来的媒体类型不鼓励注册名为 "q" 的参数.
示例:
Accept: audio/*; q=0.2, audio/basic
该值应当解释为: "我更偏好 audio/basic, 但如果任何 audio 类型在质量降低 80% 后仍是最佳可用类型, 也可以发送给我."
如果不存在 Accept 头字段, 则假定客户端接受所有媒体类型. 如果存在 Accept 头字段, 而服务器无法按照合并后的 Accept 字段值发送可接受响应, 则服务器应当发送 406 (Not Acceptable) 响应.
更复杂的示例:
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 实体."
媒体范围可以被更具体的媒体范围或具体媒体类型覆盖. 如果多个媒体范围适用于某个给定类型, 则最具体的引用具有优先级. 例如:
Accept: text/*, text/html, text/html;level=1, */*
具有如下优先级:
1) text/html;level=1
2) text/html
3) text/*
4) */*
给定类型关联的媒体类型质量因子, 由匹配该类型且优先级最高的媒体范围决定. 例如:
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
text/html;level=2;q=0.4, */*;q=0.5
会得到以下值:
text/html;level=1 = 1
text/html = 0.7
text/plain = 0.3
image/jpeg = 0.5
text/html;level=2 = 0.4
text/html;level=3 = 0.7
注意: 用户代理可以为某些媒体范围提供一组默认质量值. 但是, 除非该用户代理是无法与其他呈现代理交互的封闭系统, 否则这组默认值应当可由用户配置.
14.2 Accept-Charset
Accept-Charset 请求头字段可用于指示响应可接受哪些字符集. 该字段允许能够理解更全面或专用字符集的客户端向服务器表明此能力, 前提是服务器也能够用这些字符集表示文档.
Accept-Charset = "Accept-Charset" ":"
1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
字符集值见第 3.4 节. 每个 charset 可以带有关联的质量值, 表示用户对该字符集的偏好. 默认值为 q=1. 示例:
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
特殊值 "" 如果出现在 Accept-Charset 字段中, 将匹配该字段其他位置未提及的每个字符集, 包括 ISO-8859-1. 如果 Accept-Charset 字段中没有 "", 则所有未显式提及的字符集质量值为 0, 但 ISO-8859-1 例外: 如果未显式提及, 它的质量值为 1.
如果不存在 Accept-Charset 头, 默认是任何字符集都可接受. 如果存在 Accept-Charset 头, 而服务器无法按照该头发送可接受的响应, 则服务器应当发送带 406 (Not Acceptable) 状态码的错误响应, 但也允许发送不可接受的响应.
14.3 Accept-Encoding
Accept-Encoding 请求头字段与 Accept 类似, 但它限制响应中可接受的内容编码 (content-codings, 第 3.5 节).
Accept-Encoding = "Accept-Encoding" ":"
1#( codings [ ";" "q" "=" qvalue ] )
codings = ( content-coding | "*" )
使用示例:
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
服务器按照 Accept-Encoding 字段判断某个 content-coding 是否可接受时使用以下规则:
- 如果 content-coding 是 Accept-Encoding 字段列出的编码之一, 则它可接受, 除非附带 qvalue 为 0. qvalue 为 0 表示 "不可接受".
- Accept-Encoding 字段中的特殊符号 "*" 匹配头字段中未显式列出的任何可用 content-coding.
- 如果多个 content-coding 都可接受, 则首选非零 qvalue 最高的可接受 content-coding.
- "identity" content-coding 总是可接受, 除非 Accept-Encoding 字段包含 "identity;q=0" 而明确拒绝它, 或者字段包含 "*;q=0" 且未显式包含 "identity". 如果 Accept-Encoding 字段值为空, 则只有 "identity" 编码可接受.
如果请求中存在 Accept-Encoding 字段, 而服务器无法按照 Accept-Encoding 头发送可接受的响应, 则服务器应当发送带 406 (Not Acceptable) 状态码的错误响应.
如果请求中不存在 Accept-Encoding 字段, 服务器可以假定客户端会接受任何 content coding. 在这种情况下, 如果 "identity" 是可用的 content-coding 之一, 则服务器应当使用 "identity", 除非它有额外信息表明另一种 content-coding 对客户端有意义.
注意: 如果请求不包含 Accept-Encoding 字段且 "identity" 不可用, 则首选 HTTP/1.0 客户端通常理解的 "gzip" 和 "compress". 大多数 HTTP/1.0 应用不识别 content-codings 的 qvalues, 因此 qvalues 对 x-gzip 或 x-compress 不起作用, 也不允许与它们一起使用.
14.4 Accept-Language
Accept-Language 请求头字段与 Accept 类似, 但它限制请求响应中首选的自然语言集合. 语言标签定义见第 3.10 节.
Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] )
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
每个 language-range 可以带有关联的质量值, 表示对该范围所指定语言的用户偏好估计. 质量值默认是 "q=1". 例如:
Accept-Language: da, en-gb;q=0.8, en;q=0.7
表示: "我偏好丹麦语, 但也接受英式英语和其他英语." 当 language-range 与 language-tag 完全相等, 或者它与该标签的前缀完全相等且前缀后第一个标签字符是 "-" 时, 该范围匹配该语言标签. 特殊范围 "*" 匹配该字段其他范围未匹配的每个标签.
注意: 前缀匹配规则并不意味着语言标签总是以这样的方式分配: 如果用户理解带有某个标签的语言, 就一定理解所有以该标签为前缀的语言. 它只是允许在确实如此时使用前缀标签.
Accept-Language 字段为某个 language-tag 分配的语言质量因子, 是字段中匹配该 language-tag 的最长 language-range 的质量值. 如果没有匹配, 质量因子为 0. 如果请求中不存在 Accept-Language 头, 服务器应当假定所有语言同等可接受. 如果存在该头, 则所有质量因子大于 0 的语言都可接受.
在每个请求中发送包含用户完整语言偏好的 Accept-Language 头, 可能违背用户的隐私期望. 该问题见第 15.1.4 节. 由于可理解性高度依赖个体用户, 推荐客户端应用把语言偏好的选择提供给用户. 如果未提供此选择, 请求中禁止给出 Accept-Language 头字段.
14.5 Accept-Ranges
Accept-Ranges 响应头字段允许服务器指示它接受对某个资源的范围请求:
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
acceptable-ranges = 1#range-unit | "none"
接受字节范围请求的源服务器可以发送:
Accept-Ranges: bytes
但并非必须这样做. 即使没有收到该资源的这个头, 客户端也可以生成字节范围请求. 范围单位定义见第 3.12 节. 不接受任何范围请求的服务器可以发送:
Accept-Ranges: none
以建议客户端不要尝试范围请求.
14.6 Age
Age 响应头字段传达发送方对响应在源服务器生成以来所经过时间的估计, 或者对响应重新验证以来所经过时间的估计. 如果缓存响应的 age 不超过其 freshness lifetime, 则该响应是新鲜的. Age 值按第 13.2.3 节计算.
Age = "Age" ":" age-value
age-value = delta-seconds
Age 值是非负十进制整数, 表示秒数. 如果缓存收到大于它能表示的最大正整数的值, 或者其任何 age 计算发生溢出, 它必须传输值为 2147483648 (2^31) 的 Age 头. 包含缓存的 HTTP/1.1 服务器必须在每个由自身缓存生成的响应中包含 Age 头字段. 缓存应当使用至少 31 位范围的算术类型.
14.7 Allow
Allow 实体头字段列出由 Request-URI 标识的资源所支持的方法集合. 该字段的目的严格限于告知接收方与该资源关联的有效方法. 405 (Method Not Allowed) 响应中必须存在 Allow 头字段.
Allow = "Allow" ":" #Method
使用示例:
Allow: GET, HEAD, PUT
该字段不能阻止客户端尝试其他方法. 但是, Allow 头字段值给出的指示应当被遵循. 实际允许的方法集合由源服务器在每次请求时定义. Allow 头字段可以随 PUT 请求提供, 用于推荐新建或修改后的资源应支持的方法; 服务器不要求支持这些方法, 并且应当在响应中包含 Allow 头, 给出实际支持的方法. 代理禁止修改 Allow 头字段, 即使它不理解指定的所有方法.
14.8 Authorization
希望向服务器认证自身的用户代理, 通常但不一定是在收到 401 响应之后, 会在请求中包含 Authorization 请求头字段. Authorization 字段值由 credentials 组成, 其中包含用户代理针对所请求资源领域 (realm) 的认证信息.
Authorization = "Authorization" ":" credentials
HTTP 访问认证见 "HTTP Authentication: Basic and Digest Access Authentication" [43]. 如果请求已被认证且指定了领域, 则同一凭据应当对该领域内所有其他请求有效, 除非认证方案本身另有要求.
当共享缓存收到包含 Authorization 字段的请求时, 禁止把对应响应作为对任何其他请求的答复返回, 除非满足以下例外之一: 响应包含 "s-maxage" 指令; 响应包含 "must-revalidate" 指令且陈旧时先重新验证; 或响应包含 "public" 指令. 对 "s-maxage=0" 的响应, 代理在重用前必须始终重新验证.
14.9 Cache-Control
Cache-Control 通用头字段用于指定请求/响应链上所有缓存机制都必须遵守的指令. 这些指令指定旨在防止缓存不利地干扰请求或响应的行为, 通常会覆盖默认缓存算法. 缓存指令是单向的: 请求中出现某个指令并不意味着响应中也要给出相同指令.
注意: HTTP/1.0 缓存可能未实现 Cache-Control, 而只实现 Pragma: no-cache. 缓存指令必须由代理或网关应用透传, 不论这些指令对该应用本身有何意义.
Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive
| cache-response-directive
cache-request-directive =
"no-cache" ; Section 14.9.1
| "no-store" ; Section 14.9.2
| "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4
| "max-stale" [ "=" delta-seconds ] ; Section 14.9.3
| "min-fresh" "=" delta-seconds ; Section 14.9.3
| "no-transform" ; Section 14.9.5
| "only-if-cached" ; Section 14.9.4
| cache-extension ; Section 14.9.6
cache-response-directive =
"public" ; Section 14.9.1
| "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
| "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
| "no-store" ; Section 14.9.2
| "no-transform" ; Section 14.9.5
| "must-revalidate" ; Section 14.9.4
| "proxy-revalidate" ; Section 14.9.4
| "max-age" "=" delta-seconds ; Section 14.9.3
| "s-maxage" "=" delta-seconds ; Section 14.9.3
| cache-extension ; Section 14.9.6
cache-extension = token [ "=" ( token | quoted-string ) ]
当指令在未允许其出现的消息中出现时, 它必须被忽略. 对于未指定某个 cache-control 指令行为的应用, 必须忽略该指令.
14.9.1 什么是可缓存的 (What is Cacheable)
默认情况下, 如果请求方法、请求头字段和响应状态码指示响应可缓存, 则响应可由任意缓存存储. "public" 表示响应可以由任何缓存存储. "private" 表示响应消息整体或指定字段只面向单个用户, 禁止共享缓存存储完整响应, 但私有缓存可以存储. "no-cache" 表示响应禁止被后续请求用来满足该请求, 除非先与源服务器成功重新验证; 如果指定字段名, 则限制仅适用于这些字段.
14.9.2 缓存可以存储什么 (What May be Stored by Caches)
"no-store" 指令用于防止意外释放或保留敏感信息. 在请求中发送时, 缓存禁止存储该请求或其响应的任何部分. 在响应中发送时, 缓存禁止存储该响应或引发该响应的请求的任何部分. 该指令适用于非共享缓存和共享缓存.
14.9.3 基本过期机制的修改 (Modifications of the Basic Expiration Mechanism)
"max-age" 请求指令表示客户端愿意接受 age 不大于指定秒数的响应. "min-fresh" 表示客户端希望响应至少在指定秒数内保持新鲜. "max-stale" 表示客户端愿意接受已超过过期时间的响应; 如果给出值, 则超出时间不得多于该秒数. 在响应中, "max-age" 表示响应在生成后指定秒数内被认为新鲜. "s-maxage" 只适用于共享缓存, 并会覆盖 Expires 和 max-age.
14.9.4 缓存重新验证和重新加载控制 (Cache Revalidation and Reload Controls)
"no-cache" 请求指令强制缓存向源服务器重新验证, 即使缓存拥有看似新鲜的副本. 客户端也可以使用 "max-age=0" 强制端到端重新验证. "only-if-cached" 表示客户端只希望获得当前缓存中的响应, 不应联系源服务器. "must-revalidate" 响应指令要求缓存一旦响应变陈旧, 就禁止在未成功重新验证的情况下使用该响应. "proxy-revalidate" 与 must-revalidate 相同, 但只适用于共享缓存.
14.9.5 No-Transform 指令 (No-Transform Directive)
"no-transform" 指令表示中间缓存或代理禁止改变响应的实体主体, 包括 content-coding、media-type 或其他会改变实体语义的转换.
14.9.6 缓存控制扩展 (Cache Control Extensions)
Cache-Control 头字段可以通过一个或多个 cache-extension 令牌扩展. 缓存必须忽略无法识别的缓存指令. 信息性扩展适合以裸指令形式出现; 行为性扩展如果需要理解才能正确应用, 应结合基础指令设计以保持向后兼容.
Cache-Control: private, community="UCI"
14.10 Connection
Connection 通用头字段允许发送方指定只适用于当前连接的选项, 并且不得由代理在后续连接中转发. Connection 头中列出的每个 connection-token 都标识一个只作用于本连接的头字段, 这些字段必须在转发消息前被移除.
Connection = "Connection" ":" 1#(connection-token)
connection-token = token
HTTP/1.1 定义 "close" 连接选项, 用于表示发送方将在完成响应后关闭连接.
Connection: close
14.11 Content-Encoding
Content-Encoding 实体头字段作为 media-type 的修饰符使用. 它指出已经对实体主体应用了哪些额外内容编码, 因而需要哪些解码机制才能获得 Content-Type 头字段所引用媒体类型. Content-Encoding 主要用于允许文档在不丢失其底层媒体类型身份的情况下被压缩.
Content-Encoding = "Content-Encoding" ":" 1#content-coding
内容编码按其应用顺序列出. 示例:
Content-Encoding: gzip
如果实体的 content-coding 不是 "identity", 则响应必须包含 Content-Encoding 实体头, 列出已使用的非 identity content-codings. 如果请求消息中的实体 content-coding 对源服务器不可接受, 服务器应当以 415 (Unsupported Media Type) 响应.
14.12 Content-Language
Content-Language 实体头字段描述封闭实体面向受众的自然语言. 这不一定等同于实体主体中使用的所有语言.
Content-Language = "Content-Language" ":" 1#language-tag
语言标签定义见第 3.10 节. Content-Language 的主要目的, 是允许用户根据其偏好的语言识别和区分实体. 如果未指定 Content-Language, 默认认为内容面向所有语言受众.
Content-Language: da
Content-Language: mi, en
14.13 Content-Length
Content-Length 实体头字段以十进制八位字节数表示发送给接收方的 entity-body 大小, 或者在 HEAD 方法中表示如果请求是 GET 将会发送的 entity-body 大小.
Content-Length = "Content-Length" ":" 1*DIGIT
示例:
Content-Length: 3495
应用使用该字段时必须遵循第 4.4 节的消息长度规则. 大于等于 0 的任何 Content-Length 都是有效值. 如果消息包含非 identity transfer-coding, 则禁止发送 Content-Length, 除非该字段含义由该编码另行定义.
14.14 Content-Location
Content-Location 实体头字段可用于提供消息中封闭实体的资源位置, 当该实体可从不同于所请求资源 URI 的位置访问时尤其如此.
Content-Location = "Content-Location" ":"
( absoluteURI | relativeURI )
Content-Location 的值也定义了实体的基 URI. 如果它是相对 URI, 则相对于 Request-URI 解释. 对 PUT 或 POST 请求的响应中出现 Content-Location 并不表示实体是新资源, 也不替代 Location 的重定向或创建语义.
14.15 Content-MD5
Content-MD5 实体头字段是实体主体的 MD5 摘要, 用于提供实体主体的端到端完整性检查. 它只覆盖 entity-body, 不覆盖任何 transfer-coding 或 message-body 改变.
Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = `<base64 of 128 bit MD5 digest as per RFC 1864>`
摘要按 RFC 1864 的规则计算和编码. 只有产生实体的源服务器或客户端可以生成 Content-MD5; 代理和网关禁止生成它, 因为这会破坏端到端语义. 接收方可以检查该值并在发现不匹配时把实体视为被修改.
14.16 Content-Range
Content-Range 实体头字段随部分 entity-body 发送, 用于指出该部分在完整 entity-body 中应放置的位置, 或者指出请求的范围无法满足.
Content-Range = "Content-Range" ":" content-range-spec
content-range-spec = byte-content-range-spec
byte-content-range-spec = bytes-unit SP
byte-range-resp-spec "/"
( instance-length | "*" )
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
| "*"
instance-length = 1*DIGIT
byte-content-range-spec 中的 first-byte-pos 表示第一个字节的位置, last-byte-pos 表示最后一个字节的位置, 二者都是包含端点的字节偏移. instance-length 表示当前所选变体的长度. 如果长度未知, 使用 "*".
示例值, 假定实体总共包含 1234 字节:
bytes 0-499/1234
bytes 500-999/1234
bytes 500-1233/1234
bytes 734-1233/1234
当 HTTP 消息包含单个范围的内容时, 该内容用 Content-Range 头和表示实际传输字节数的 Content-Length 头传输. 例如:
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
包含多个范围内容的 HTTP 消息以 multipart 消息传输, 媒体类型为 "multipart/byteranges". 对单个范围请求的响应禁止使用 multipart/byteranges 媒体类型发送. 对多个范围请求且结果为单一范围的响应可以作为带一个 part 的 multipart/byteranges 发送. 不能解码 multipart/byteranges 消息的客户端禁止在单个请求中请求多个 byte-ranges.
如果服务器忽略语法无效的 byte-range-spec, 它应当像无效 Range 头字段不存在一样处理请求. 如果服务器收到不含 If-Range 的请求且 Range 不可满足, 它应当返回 416 (Requested range not satisfiable). 客户端不能依赖所有服务器都这样做.
14.17 Content-Type
Content-Type 实体头字段指出发送给接收方的 entity-body 的媒体类型, 或者在 HEAD 方法中指出如果请求是 GET 将会发送的媒体类型.
Content-Type = "Content-Type" ":" media-type
媒体类型定义见第 3.7 节. 示例:
Content-Type: text/html; charset=ISO-8859-4
识别实体媒体类型的方法见第 7.2.1 节.
14.18 Date
Date 通用头字段表示消息产生的日期和时间, 其语义与 RFC 822 的 orig-date 相同. 字段值是第 3.3.1 节描述的 HTTP-date; 它必须以 RFC 1123 日期格式发送.
Date = "Date" ":" HTTP-date
示例:
Date: Tue, 15 Nov 1994 08:12:31 GMT
源服务器必须在所有响应中包含 Date 头字段, 但以下情况除外: 状态码为 100 或 101 时可以选择包含; 状态码表示服务器错误且生成有效 Date 不方便或不可能时可以省略; 没有能提供当前时间合理近似值的时钟时禁止包含 Date, 并且必须遵循第 14.18.1 节规则.
接收方收到没有 Date 头字段的消息时, 如果该消息将被缓存或经由要求 Date 的协议网关转发, 则必须为其分配一个 Date. 没有时钟的 HTTP 实现禁止缓存响应, 除非每次使用前重新验证. HTTP 缓存, 尤其是共享缓存, 应当使用 NTP [28] 等机制把时钟与可靠外部标准同步.
客户端应当只在包含 entity-body 的消息中发送 Date 头字段, 如 PUT 和 POST 请求, 即便如此也是可选的. 没有时钟的客户端禁止在请求中发送 Date 头字段. Date 头中的 HTTP-date 不应表示晚于消息生成的日期和时间.
14.18.1 无时钟源服务器操作 (Clockless Origin Server Operation)
某些源服务器实现可能没有可用时钟. 没有时钟的源服务器禁止为响应分配 Expires 或 Last-Modified 值, 除非这些值由拥有可靠时钟的系统或用户与资源关联. 它可以分配一个在服务器配置时或之前已知位于过去的 Expires 值, 这允许在不为每个资源单独存储 Expires 值的情况下让响应预过期.
14.19 ETag
ETag 响应头字段提供所请求变体的当前实体标签值. 与实体标签配合使用的头见第 14.24、14.26 和 14.44 节. 实体标签可以用于与同一资源的其他实体比较.
ETag = "ETag" ":" entity-tag
示例:
ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""
14.20 Expect
Expect 请求头字段用于指示客户端要求特定服务器行为.
Expect = "Expect" ":" 1#expectation
expectation = "100-continue" | expectation-extension
expectation-extension = token [ "=" ( token | quoted-string )
*expect-params ]
expect-params = ";" token [ "=" ( token | quoted-string ) ]
服务器如果不理解或无法遵守请求 Expect 字段中的任何期望值, 必须用适当错误状态响应. 如果任何期望无法满足, 服务器必须响应 417 (Expectation Failed); 如果请求存在其他问题, 则响应其他 4xx 状态.
该头字段使用可扩展语法定义, 以允许未来扩展. 如果服务器收到包含其不支持的 expectation-extension 的 Expect 字段, 必须响应 417. 未加引号的 token 的期望值比较不区分大小写; quoted-string expectation-extensions 区分大小写. Expect 机制是逐跳的, 但 Expect 请求头本身是端到端的; 如果请求被转发, 它也必须被转发.
14.21 Expires
Expires 实体头字段给出响应在其后被认为陈旧的日期/时间. 陈旧缓存条目通常不得由缓存返回, 除非先与源服务器验证, 或与拥有新鲜实体副本的中间缓存验证. 过期模型见第 13.2 节.
Expires 字段的存在并不意味着原始资源会在该时间点之前、当时或之后改变或停止存在. 格式是第 3.3.1 节中 HTTP-date 定义的绝对日期和时间; 它必须采用 RFC 1123 日期格式:
Expires = "Expires" ":" HTTP-date
使用示例:
Expires: Thu, 01 Dec 1994 16:00:00 GMT
注意: 如果响应包含带 max-age 指令的 Cache-Control 字段, 该指令会覆盖 Expires 字段. HTTP/1.1 客户端和缓存必须把其他无效日期格式, 特别是值 "0", 视为过去时间. 要标记响应为已经过期, 源服务器发送与 Date 头值相等的 Expires 日期. 要标记响应为永不过期, 源服务器发送从响应发送时间起约一年后的 Expires 日期. HTTP/1.1 服务器不应发送超过未来一年以上的 Expires 日期.
如果一个默认不可缓存的响应带有未来日期值的 Expires 头字段, 则表示该响应可缓存, 除非 Cache-Control 头字段另有指示.
14.22 From
From 请求头字段如果给出, 应当包含控制发出请求的用户代理的人类用户的 Internet 电子邮件地址. 该地址应当按 RFC 822 [9] 中由 RFC 1123 [8] 更新的 "mailbox" 定义, 可由机器使用:
From = "From" ":" mailbox
示例:
From: [email protected]
该头字段可以用于日志记录, 也可用于识别无效或不想要请求的来源. 它不应作为不安全的访问保护形式使用. 该字段的含义是请求代表所给出的人执行, 该人对执行的方法承担责任. 机器人代理尤其应当包含该头, 以便接收端出现问题时能联系运行机器人的负责人. 客户端不应在未经用户批准的情况下发送 From 头字段.
14.23 Host
Host 请求头字段指定被请求资源的 Internet 主机和端口号, 该值来自用户或引用资源给出的原始 URI. Host 字段值必须表示原始 URL 给出的源服务器或网关的命名权威. 这允许源服务器或网关区分内部有歧义的 URL.
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
没有尾随端口信息的 "host" 表示所请求服务的默认端口. 例如:
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
客户端必须在所有 HTTP/1.1 请求消息中包含 Host 头字段. 如果被请求 URI 不包含所请求服务的 Internet 主机名, 则 Host 头字段必须以空值给出. HTTP/1.1 代理必须确保其转发的任何请求消息都包含适当的 Host 头字段. 所有基于 Internet 的 HTTP/1.1 服务器必须对缺少 Host 头字段的任何 HTTP/1.1 请求消息响应 400 (Bad Request).
14.24 If-Match
If-Match 请求头字段与某个方法一起使用, 使该方法成为条件方法. 已从资源获取一个或多个实体的客户端, 可以通过在 If-Match 头字段中包含这些实体关联的实体标签列表, 验证其中某个实体是否仍是当前实体. 特殊值 "*" 匹配资源的任意当前实体.
If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
如果任何实体标签匹配该资源上类似 GET 请求将返回的实体标签, 或者给出 "*" 且该资源存在任何当前实体, 则服务器可以像不存在 If-Match 头字段一样执行所请求的方法. 服务器必须使用强比较函数比较 If-Match 中的实体标签.
如果没有实体标签匹配, 或者给出 "*" 但不存在当前实体, 服务器禁止执行所请求的方法, 并且必须返回 412 (Precondition Failed) 响应. 如果没有 If-Match 头字段时请求会导致 2xx 或 412 之外的状态, 则必须忽略 If-Match 头.
If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *
同时带有 If-Match 头字段以及 If-None-Match 或 If-Modified-Since 头字段的请求结果, 本规范未定义.
14.25 If-Modified-Since
If-Modified-Since 请求头字段与某个方法一起使用, 使该方法成为条件方法: 如果所请求变体自该字段指定时间以来未被修改, 服务器不会返回实体, 而是返回不含 message-body 的 304 (Not Modified) 响应.
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
示例:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
带 If-Modified-Since 头且不带 Range 头的 GET 方法请求, 要求仅当所标识实体自给定日期以来已被修改时才传输该实体. 如果请求通常会产生 200 之外的状态, 或给出的日期无效, 响应与普通 GET 相同; 如果变体自该日期以来已被修改, 响应与普通 GET 相同; 如果未被修改, 服务器应当返回 304.
该功能用于以最小事务开销高效更新缓存信息. Range 请求头字段会修改 If-Modified-Since 的含义. If-Modified-Since 时间由服务器解释, 服务器时钟可能未与客户端同步. 为获得最佳缓存验证效果, 客户端应尽可能使用先前 Last-Modified 头字段中收到的精确日期字符串.
14.26 If-None-Match
If-None-Match 请求头字段与某个方法一起使用, 使该方法成为条件方法. 已从资源获取一个或多个实体的客户端, 可以通过在 If-None-Match 头字段中包含这些实体关联的实体标签列表, 验证这些实体都不是当前实体. 特殊值 "*" 匹配资源的任意当前实体.
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
如果任何实体标签匹配该资源上类似 GET 请求将返回的实体标签, 或者给出 "*" 且该资源存在任何当前实体, 则服务器禁止执行所请求的方法, 除非因为请求中的 If-Modified-Since 头字段与资源修改日期不匹配而必须执行. 如果请求方法是 GET 或 HEAD, 服务器应当响应 304 并包含匹配实体之一的缓存相关头字段. 对所有其他请求方法, 服务器必须响应 412.
如果没有实体标签匹配, 则服务器可以像不存在 If-None-Match 头字段一样执行所请求的方法, 但也必须忽略请求中的任何 If-Modified-Since 头字段. 如果没有 If-None-Match 头字段时请求会导致 2xx 或 304 之外的状态, 则必须忽略 If-None-Match 头.
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 头字段以及 If-Match 或 If-Unmodified-Since 头字段的请求结果, 本规范未定义.
14.27 If-Range
如果客户端在其缓存中有某个实体的部分副本, 并希望得到整个实体的最新副本, 它可以把 Range 请求头与条件 GET 一起使用. 但是如果条件失败, 客户端还需要第二个请求来获取完整当前 entity-body.
If-Range 头允许客户端短路第二个请求. 非正式地说, 它的含义是: 如果实体未改变, 发送我缺少的部分; 否则, 发送整个新实体.
If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
如果客户端没有某实体的实体标签, 但有 Last-Modified 日期, 它可以在 If-Range 头中使用该日期. If-Range 头应当只与 Range 头一起使用; 如果请求不包含 Range 头, 或服务器不支持子范围操作, 则必须忽略它. 如果实体标签匹配, 服务器应当用 206 响应提供指定子范围; 如果不匹配, 服务器应当用 200 响应返回完整实体.
14.28 If-Unmodified-Since
If-Unmodified-Since 请求头字段与某个方法一起使用, 使该方法成为条件方法. 如果所请求资源自该字段指定时间以来未被修改, 服务器应当像不存在 If-Unmodified-Since 头一样执行所请求操作.
如果所请求变体自指定时间以来已被修改, 服务器禁止执行所请求操作, 并且必须返回 412 (Precondition Failed).
If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
示例:
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
如果请求在没有 If-Unmodified-Since 头时通常会导致 2xx 或 412 之外的状态, 则应当忽略 If-Unmodified-Since 头. 如果指定日期无效, 忽略该头. 同时带有 If-Unmodified-Since 头字段以及 If-None-Match 或 If-Modified-Since 头字段的请求结果, 本规范未定义.
14.29 Last-Modified
Last-Modified 实体头字段指出源服务器认为该变体最后被修改的日期和时间.
Last-Modified = "Last-Modified" ":" HTTP-date
使用示例:
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
该头字段的精确含义取决于源服务器实现和原始资源性质. 对文件而言, 它可能是文件系统最后修改时间; 对动态实体而言, 它可能是组成部分最后修改时间中的最新值; 对数据库网关而言, 它可能是记录的最后更新时间戳; 对虚拟对象而言, 它可能是内部状态最后变化的时间.
源服务器禁止发送晚于服务器消息产生时间的 Last-Modified 日期. 如果资源的最后修改时间指向未来, 服务器必须用消息产生日期替换该日期. 源服务器应当尽可能在接近生成响应 Date 值的时间取得实体的 Last-Modified 值. HTTP/1.1 服务器应当在可行时发送 Last-Modified.
14.30 Location
Location 响应头字段用于把接收方重定向到 Request-URI 之外的位置以完成请求, 或用于标识新资源. 对 201 (Created) 响应, Location 是该请求创建的新资源位置. 对 3xx 响应, 该位置应当指出服务器首选的自动重定向 URI. 字段值由单个绝对 URI 组成.
Location = "Location" ":" absoluteURI
示例:
Location: http://www.w3.org/pub/WWW/People.html
注意: Content-Location 头字段与 Location 不同, 因为 Content-Location 标识请求中封闭实体的原始位置. 因此响应可能同时包含 Location 和 Content-Location.
14.31 Max-Forwards
Max-Forwards 请求头字段为 TRACE 和 OPTIONS 方法提供一种机制, 用于限制能把请求转发到下一个入站服务器的代理或网关数量. 当客户端试图追踪一条似乎在中间失败或循环的请求链时, 这很有用.
Max-Forwards = "Max-Forwards" ":" 1*DIGIT
Max-Forwards 值是十进制整数, 表示该请求消息还可以被转发的次数. 每个收到包含 Max-Forwards 头字段的 TRACE 或 OPTIONS 请求的代理或网关, 在转发请求前必须检查并更新其值. 如果收到的值为 0, 接收方禁止转发请求; 它必须作为最终接收方响应. 如果值大于 0, 转发消息必须包含递减 1 后的 Max-Forwards 字段.
对于本规范定义的所有其他方法以及未在方法定义中显式引用 Max-Forwards 的任何扩展方法, 可以忽略 Max-Forwards 头字段.
14.32 Pragma
Pragma 通用头字段用于包含实现特定的指令, 这些指令可能适用于请求/响应链上的任何接收方. 所有 pragma 指令从协议角度看都指定可选行为; 但某些系统可以要求行为与这些指令一致.
Pragma = "Pragma" ":" 1#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" ( token | quoted-string ) ]
当请求消息中存在 no-cache 指令时, 应用应当把请求转发给源服务器, 即使它拥有所请求内容的缓存副本. 该 pragma 指令与 no-cache cache-directive 具有相同语义, 并在此为与 HTTP/1.0 向后兼容而定义. 当向未知是否兼容 HTTP/1.1 的服务器发送 no-cache 请求时, 客户端应当同时包含两个头字段.
Pragma 指令必须由代理或网关应用透传. 无法为特定接收方指定 pragma; 与某接收方无关的 pragma 指令应当被该接收方忽略. HTTP/1.1 缓存应当把 "Pragma: no-cache" 视为客户端发送了 "Cache-Control: no-cache". HTTP 中不会定义新的 Pragma 指令.
14.33 Proxy-Authenticate
Proxy-Authenticate 响应头字段必须作为 407 (Proxy Authentication Required) 响应的一部分包含. 字段值由 challenge 组成, 指出适用于该 Request-URI 的代理的认证方案和参数.
Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge
HTTP 访问认证过程见 "HTTP Authentication: Basic and Digest Access Authentication" [43]. 与 WWW-Authenticate 不同, Proxy-Authenticate 头字段只适用于当前连接, 不应传递给下游客户端. 但是, 中间代理可能需要通过向下游客户端请求凭据来获得自己的凭据.
14.34 Proxy-Authorization
Proxy-Authorization 请求头字段允许客户端向需要认证的代理标识自身或其用户. Proxy-Authorization 字段值由 credentials 组成, 包含用户代理针对代理和/或所请求资源领域的认证信息.
Proxy-Authorization = "Proxy-Authorization" ":" credentials
与 Authorization 不同, Proxy-Authorization 头字段只适用于使用 Proxy-Authenticate 字段要求认证的下一个出站代理. 当链中使用多个代理时, Proxy-Authorization 头字段由第一个期望接收凭据的出站代理消费. 如果这是代理协同认证某个请求的机制, 代理可以把客户端请求中的凭据中继给下一个代理.
14.35 Range
14.35.1 字节范围 (Byte Ranges)
由于所有 HTTP 实体在 HTTP 消息中都表示为字节序列, 字节范围概念对任何 HTTP 实体都有意义. 字节范围规范应用于 entity-body 中的字节序列, 该序列不一定与 message-body 相同. 字节范围操作可以指定单个字节范围, 也可以指定单个实体内的一组范围.
ranges-specifier = byte-ranges-specifier
byte-ranges-specifier = bytes-unit "=" byte-range-set
byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
byte-range-spec = first-byte-pos "-" [last-byte-pos]
first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT
byte-range-spec 中的 first-byte-pos 值给出范围中第一个字节的字节偏移. last-byte-pos 值给出范围中最后一个字节的字节偏移; 指定的字节位置是包含端点的. 字节偏移从 0 开始.
如果 last-byte-pos 存在, 它必须大于或等于 first-byte-pos, 否则语法无效. 接收方收到包含一个或多个语法无效 byte-range-spec 值的 byte-range-set 时, 必须忽略包含该 byte-range-set 的头字段. 如果 last-byte-pos 不存在或超过当前 entity-body 长度, 则视为当前 entity-body 长度减一.
suffix-byte-range-spec = "-" suffix-length
suffix-length = 1*DIGIT
suffix-byte-range-spec 用于指定 entity-body 的后缀, 长度由 suffix-length 给出. 如果实体短于指定 suffix-length, 则使用整个 entity-body.
如果语法有效的 byte-range-set 至少包含一个 first-byte-pos 小于当前 entity-body 长度的 byte-range-spec, 或至少包含一个非零 suffix-length 的 suffix-byte-range-spec, 则该 byte-range-set 可满足. 否则不可满足. 不可满足时服务器应当返回 416; 可满足时服务器应当返回 206, 其中包含 entity-body 的可满足范围.
bytes=0-499
bytes=500-999
bytes=-500
bytes=9500-
bytes=0-0,-1
bytes=500-600,601-999
bytes=500-700,601-999
14.35.2 范围获取请求 (Range Retrieval Requests)
使用条件或无条件 GET 方法的 HTTP 获取请求, 可以使用 Range 请求头请求实体的一个或多个子范围, 而不是整个实体. Range 应用于作为请求结果返回的实体:
Range = "Range" ":" ranges-specifier
服务器可以忽略 Range 头. 但是 HTTP/1.1 源服务器和中间缓存应在可能时支持字节范围, 因为 Range 支持从部分失败传输中高效恢复, 也支持高效获取大型实体的一部分.
如果服务器支持 Range 且范围适用于实体, 无条件 GET 的成功响应为 206 而不是 200. 条件 GET 中, Range 只在 GET 原本成功且条件为真时修改返回内容; 如果条件为假而返回 304, Range 不产生影响. 某些情况下, 使用 If-Range 更合适. 如果支持范围的代理收到 Range 请求并从入站服务器收到完整实体, 它应当只向客户端返回请求的范围, 并可按缓存策略存储完整响应.
14.36 Referer
Referer[sic] 请求头字段允许客户端为了服务器的利益, 指定获得 Request-URI 的来源资源地址 (URI), 即 "referrer", 尽管该头字段拼写错误. Referer 请求头允许服务器生成指向资源的反向链接列表, 用于关注度分析、日志、优化缓存等. 它也允许追踪过时或拼写错误的链接以便维护. 如果 Request-URI 来自没有自身 URI 的来源, 例如用户键盘输入, 则禁止发送 Referer 字段.
Referer = "Referer" ":" ( absoluteURI | relativeURI )
示例:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
如果字段值是相对 URI, 应当相对于 Request-URI 解释. URI 禁止包含 fragment. 安全考虑见第 15.1.3 节.
14.37 Retry-After
Retry-After 响应头字段可与 503 (Service Unavailable) 响应一起使用, 指出服务预计对请求客户端不可用多长时间. 该字段也可以与任何 3xx 响应一起使用, 指出要求用户代理在发出重定向请求前等待的最短时间. 字段值可以是 HTTP-date, 也可以是响应时间之后的十进制秒数整数.
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
示例:
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
后一示例中的延迟为 2 分钟.
14.38 Server
Server 响应头字段包含源服务器处理请求所用软件的信息. 该字段可以包含多个 product 令牌和注释, 用于标识服务器及任何重要子产品. product 令牌按其对标识应用的重要性排序.
Server = "Server" ":" 1*( product | comment )
示例:
Server: CERN/3.0 libwww/2.17
如果响应通过代理转发, 代理应用禁止修改 Server 响应头. 暴露具体服务器软件版本可能让服务器更容易遭受针对已知安全漏洞的攻击, 因此鼓励服务器实现把该字段设为可配置选项.
14.39 TE
TE 请求头字段指出客户端愿意在响应中接受哪些扩展传输编码, 以及它是否愿意接受 chunked 传输编码中的 trailer 字段. TE 字段只应用于直接连接.
TE = "TE" ":" #( t-codings )
t-codings = "trailers" | ( transfer-extension [ accept-params ] )
"trailers" 关键字表示客户端愿意接受 chunked 响应中 trailer 字段. 传输编码可以带有 qvalue 参数来表示相对偏好. 示例:
TE: deflate
TE:
TE: trailers, deflate;q=0.5
如果 TE 字段值为空或不存在, 唯一可接受的 transfer-coding 是 "chunked". 包含 TE 的消息也必须在 Connection 头中包含 "TE", 以防止它被不支持该扩展的中间方转发.
14.40 Trailer
Trailer 通用字段值表示给定的一组头字段将出现在以 chunked transfer-coding 编码的消息的 trailer 中. 这允许接收方在开始处理主体前知道哪些头字段会在结尾出现.
Trailer = "Trailer" ":" 1#field-name
消息头字段如果是传输框架、路由、认证、响应控制或决定如何处理实体的字段, 禁止出现在 trailer 中. Trailer 字段必须随 chunked transfer-coding 一起使用.
14.41 Transfer-Encoding
Transfer-Encoding 通用头字段指出为了在发送方和接收方之间安全传输 message-body, 已经对其应用了哪种传输编码. 这不同于 Content-Encoding, 因为 transfer-coding 是消息属性, 而不是实体属性.
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
传输编码定义见第 3.6 节. 示例:
Transfer-Encoding: chunked
如果消息使用非 identity transfer-coding, 则 Transfer-Encoding 头字段必须列出这些编码. Transfer-Encoding 会覆盖 Content-Length 对消息长度的指示, 相关规则见第 4.4 节.
14.42 Upgrade
Upgrade 通用头字段允许客户端指定它支持哪些额外通信协议, 并且愿意在服务器认为适当时切换协议. 服务器必须使用 101 (Switching Protocols) 响应来表示它同意切换.
Upgrade = "Upgrade" ":" 1#product
示例:
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Upgrade 头字段只适用于直接连接. 因此, 发送 Upgrade 的客户端必须同时在 Connection 头字段中发送 "Upgrade", 以防止代理盲目转发. Upgrade 不能用于强制协议改变; 服务器可以忽略它.
14.43 User-Agent
User-Agent 请求头字段包含发起请求的用户代理的信息. 这用于统计、协议违规追踪, 以及为特定用户代理自动识别以避免限制. 用户代理应当包含多个 product 令牌和注释, 按其对标识应用的重要性排序.
User-Agent = "User-Agent" ":" 1*( product | comment )
示例:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
用户代理不应在 User-Agent 字段中包含不必要的细节, 因为这可能暴露实现细节并增加隐私风险. 代理禁止修改 User-Agent 字段, 即使它不能理解其中的所有 product 令牌.
14.44 Vary
Vary 响应头字段描述请求消息中除方法和 Request-URI 之外的哪些字段会完全决定响应是否可用于后续请求, 而不需要重新验证. 对缓存而言, Vary 用于判断已存响应是否匹配新的请求.
Vary = "Vary" ":" ( "*" | 1#field-name )
"*" 值表示响应选择受到未列出的参数影响, 因而缓存不能根据后续请求判断响应是否适用. field-name 列表表示被列出的请求头字段会影响响应选择. 缓存在使用带 Vary 的响应前, 必须比较新请求和原始请求中这些字段的值.
14.45 Via
Via 通用头字段必须由网关和代理使用, 以指示请求经过的中间协议和接收方. 它类似于电子邮件中的 Received 字段, 可用于追踪消息转发, 避免请求循环, 并识别请求/响应链上发送方的协议能力.
Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token
protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym
pseudonym = token
网关和代理必须在每条转发消息中附加自己的 Via 条目. received-protocol 表示中间应用收到消息时使用的协议和版本. received-by 标识接收方主机和可选端口, 或使用 pseudonym. 注释可以用于标识接收方代理或网关的软件.
示例:
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
作为网络防火墙门户的代理和网关默认不应转发防火墙区域内主机的名称和端口. 只有在显式启用时才应传播这些信息. 如未启用, 防火墙后任何主机的 received-by 主机应当替换为适当的 pseudonym.
对于有强隐私要求、需要隐藏内部结构的组织, 代理可以把 received-protocol 值相同的有序 Via 条目子序列合并为单个条目. 例如:
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
应用不应合并多个条目, 除非它们都处于同一组织控制之下且主机已被替换为 pseudonym. 应用禁止合并 received-protocol 值不同的条目.
14.46 Warning
Warning 通用头字段用于携带关于消息状态或转换的附加信息, 这些信息可能未在消息中反映出来. 这些信息通常用于警告缓存操作或对消息 entity-body 应用转换可能导致语义透明性不足.
Warning 头随响应发送:
Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
[SP warn-date]
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
warn-date = `<">` HTTP-date `<">`
响应可以携带多个 Warning 头. warn-text 应当使用接收响应的人类用户最可能理解的自然语言和字符集. 默认语言为英语, 默认字符集为 ISO-8859-1. 如果使用 ISO-8859-1 之外的字符集, 必须用 RFC 2047 [14] 描述的方法在 warn-text 中编码.
Warning 头通常可应用于任何消息, 但某些 warn-code 专用于缓存, 只能应用于响应消息. 新 Warning 头应当添加在已有 Warning 头之后. 缓存禁止删除随消息收到的任何 Warning 头. 但是, 如果缓存成功验证缓存条目, 除特定 Warning code 另有规定外, 它应当移除先前附加到该条目的 Warning 头. 然后它必须添加验证响应中收到的任何 Warning 头.
当响应附加多个 Warning 头时, 用户代理应尽可能按它们在响应中出现的顺序告知用户. 如果无法告知所有警告, 用户代理应当优先显示响应中较早出现的警告, 以及在 warn-code 和 warn-agent 相同的情况下使用用户首选字符集的警告.
当前定义的 warn-code 如下:
110 Response is stale
每当返回的响应已陈旧时必须包含.
111 Revalidation failed
如果缓存因为无法联系服务器而重新验证失败, 因此返回陈旧响应, 则必须包含.
112 Disconnected operation
如果缓存有意在一段时间内与网络其他部分断开连接, 则应当包含.
113 Heuristic expiration
如果缓存用启发式方法选择了超过 24 小时的新鲜寿命, 且响应 age 超过 24 小时, 则必须包含.
199 Miscellaneous warning
警告文本可以包含任意要呈现给人类用户或记录的信息. 收到此警告的系统除向用户呈现警告外, 禁止采取任何自动动作.
214 Transformation applied
如果中间缓存或代理应用了任何改变响应 content-coding、media-type 或 entity-body 的转换, 必须添加该警告, 除非响应中已出现此 Warning code.
299 Miscellaneous persistent warning
警告文本可以包含任意要呈现给人类用户或记录的信息. 收到此警告的系统禁止采取任何自动动作.
如果实现发送带有一个或多个 Warning 头且版本为 HTTP/1.0 或更低的消息, 发送方必须在每个 warning-value 中包含与响应 Date 匹配的 warn-date. 如果实现收到包含 warn-date 的 warning-value, 且该 warn-date 与响应 Date 值不同, 则在存储、转发或使用消息前必须删除该 warning-value. 如果因此删除了所有 warning-values, 也必须删除 Warning 头.
14.47 WWW-Authenticate
WWW-Authenticate 响应头字段必须包含在 401 (Unauthorized) 响应消息中. 字段值由至少一个 challenge 组成, 指出适用于 Request-URI 的认证方案和参数.
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
HTTP 访问认证过程见 "HTTP Authentication: Basic and Digest Access Authentication" [43]. 建议用户代理在解析 WWW-Authenticate 字段值时特别小心, 因为它可能包含多个 challenge; 或者如果提供了多个 WWW-Authenticate 头字段, challenge 本身的内容也可能包含逗号分隔的认证参数列表.