Skip to main content

6. Precedence (优先级)

当请求中存在多个条件请求头字段时, 字段评估的顺序变得很重要。在实践中, 本文档中定义的字段始终以单一、逻辑的顺序实现, 因为"丢失更新"前提条件比缓存验证具有更严格的要求, 并且实体标签被认为比日期值更准确。

接收方缓存或源服务器必须 (MUST) 按以下顺序评估本规范定义的请求前提条件:

  1. 当接收方是源服务器且存在 If-Match 时, 评估 If-Match 前提条件:

    • 如果为 true, 继续执行步骤 3
    • 如果为 false, 响应 412 (Precondition Failed), 除非可以确定状态改变请求已经成功 (见第 3.1 节)
  2. 当接收方是源服务器, If-Match 不存在, 且存在 If-Unmodified-Since 时, 评估 If-Unmodified-Since 前提条件:

    • 如果为 true, 继续执行步骤 3
    • 如果为 false, 响应 412 (Precondition Failed), 除非可以确定状态改变请求已经成功 (见第 3.4 节)
  3. 当存在 If-None-Match 时, 评估 If-None-Match 前提条件:

    • 如果为 true, 继续执行步骤 5
    • 如果对于 GET/HEAD 为 false, 响应 304 (Not Modified)
    • 如果对于其他方法为 false, 响应 412 (Precondition Failed)
  4. 当方法是 GET 或 HEAD, If-None-Match 不存在, 且存在 If-Modified-Since 时, 评估 If-Modified-Since 前提条件:

    • 如果为 true, 继续执行步骤 5
    • 如果为 false, 响应 304 (Not Modified)
  5. 当方法是 GET 且同时存在 RangeIf-Range 时, 评估 If-Range 前提条件:

    • 如果为 true 且 Range 规范适用于所选表示, 响应 206 (Partial Content) [RFC7233]
    • 否则, 忽略 Range 头字段并响应 200 (OK)
  6. 否则,

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

任何定义额外条件请求头字段的 HTTP 扩展都应该定义其相对于本文档中定义的条件请求头字段的评估顺序。允许扩展字段重新定义标准条件头字段的优先级, 或依赖于标准字段的评估结果, 将导致模糊或不一致的行为。