跳到主要内容

6. 优先级 (Precedence)

当一个请求中存在多个条件请求头字段时, 字段求值的顺序就变得重要. 实践中, 本文档定义的字段会按单一的逻辑顺序一致实现, 因为 "lost update" 前置条件比缓存验证有更严格的要求, 并且 entity-tag 被认为比日期值更准确.

接收方缓存或源服务器 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 且同时存在 Range 和 If-Range 时, 对 If-Range 前置条件求值:

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

  6. 否则:

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

任何定义额外条件请求头字段的 HTTP 扩展都应定义其自身相对于本文档所定义条件请求头字段的求值顺序. 允许扩展字段重新定义标准条件头字段的优先级, 或依赖标准字段的求值结果, 会导致含糊或不一致的行为.

最后于 更新