Skip to main content

1. Introduction (简介)

条件请求是包含一个或多个头字段的 HTTP 请求 [RFC7231], 这些头字段指示在将方法语义应用于目标资源之前要测试的前提条件。本文档根据 [RFC7230] 中定义的架构、语法标记和一致性标准来定义 HTTP/1.1 条件请求机制。

条件 GET 请求是 HTTP 缓存更新最高效的机制 [RFC7234]。条件也可以应用于状态改变方法, 如 PUT 和 DELETE, 以防止"丢失更新"问题: 一个客户端意外覆盖了另一个并行工作的客户端的工作。

条件请求前提条件基于目标资源的整体状态 (其当前值集) 或在先前获得的表示中观察到的状态 (该集合中的一个值)。一个资源可能有多个当前表示, 每个表示都有其自己的可观察状态。条件请求机制假设, 如果服务器打算利用条件, 那么请求到"所选表示" (selected representation) (参见 [RFC7231] 第 3 节) 的映射将随时间保持一致。无论如何, 如果映射不一致且服务器无法选择适当的表示, 那么当前提条件评估为 false 时不会造成任何损害。

本规范定义的条件请求前提条件 (第 3 节) 在适用于接收者时 (第 5 节) 根据其优先级顺序 (第 6 节) 进行评估。

1.1. Conformance and Error Handling (一致性与错误处理)​

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 以及 "OPTIONAL" 应按照 [RFC2119] 中描述的方式进行解释。

  • MUST / REQUIRED / SHALL: 绝对必须
  • MUST NOT / SHALL NOT: 绝对不能
  • SHOULD / RECOMMENDED: 应该
  • SHOULD NOT / NOT RECOMMENDED: 不应该
  • MAY / OPTIONAL: 可以

关于错误处理的一致性标准和考虑事项在 [RFC7230] 的第 2.5 节中定义。

1.2. Syntax Notation (语法标记)​

本规范使用 [RFC5234] 的增强巴科斯-诺尔范式 (Augmented Backus-Naur Form, ABNF) 标记法, 并使用 [RFC7230] 第 7 节中定义的列表扩展, 该扩展允许使用 '#' 运算符对逗号分隔的列表进行紧凑定义 (类似于 '*' 运算符表示重复)。附录 B 描述了从其他文档导入的规则。附录 C 显示了收集的语法, 其中所有列表运算符都扩展为标准 ABNF 标记法。

Last updated on