Skip to main content

6. Precedence

When more than one conditional request header field is present in a request, the order in which the fields are evaluated becomes important. In practice, the fields defined in this document are consistently implemented in a single, logical order, since "lost update" preconditions have more strict requirements than cache validation, and an entity-tag is presumed to be more accurate than a date value.

A recipient cache or origin server MUST evaluate the request preconditions defined by this specification in the following order:

  1. When recipient is the origin server and If-Match is present, evaluate the If-Match precondition:

    • if true, continue to step 3
    • if false, respond 412 (Precondition Failed) unless it can be determined that the state-changing request has already succeeded (see Section 3.1)

  2. When recipient is the origin server, If-Match is not present, and If-Unmodified-Since is present, evaluate the If-Unmodified-Since precondition:

    • if true, continue to step 3
    • if false, respond 412 (Precondition Failed) unless it can be determined that the state-changing request has already succeeded (see Section 3.4)

  3. When If-None-Match is present, evaluate the If-None-Match precondition:

    • if true, continue to step 5
    • if false for GET/HEAD, respond 304 (Not Modified)
    • if false for other methods, respond 412 (Precondition Failed)

  4. When the method is GET or HEAD, If-None-Match is not present, and If-Modified-Since is present, evaluate the If-Modified-Since precondition:

    • if true, continue to step 5
    • if false, respond 304 (Not Modified)

  5. When the method is GET and both Range and If-Range are present, evaluate the If-Range precondition:

    • if true and the Range specification is applicable to the selected representation, respond 206 (Partial Content) [RFC7233]
    • otherwise, ignore the Range header field and respond 200 (OK)

  6. Otherwise,

    • perform the requested method and respond according to its success or failure.

Any extension to HTTP that defines additional conditional request header fields ought to define its own order of evaluation relative to the conditional request header fields defined in this document. Allowing extension fields to redefine the precedence of standard conditional header fields, or to depend on a standard field's evaluation outcome, would lead to ambiguous or inconsistent behavior.

Last updated on