Subject: If header field and conditional precedence

From: Ken Murchison <[email-masked]>
Date: Sun, 23 Dec 2012 16:00:46 -0500

Happy Holidays to All!

I'm trying to figure out where the If header field fits in the 
precedence order outlined in:
http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-21#section-5

I assume that the If header field should be evaluated in a step 0, but 
my question is what should happen when the If header is present and 
evaluates to true?  Should processing continue to step 3 or step 1?  In 
other words, does If completely supersede If-Match, where a client 
wishing to submit both a state token and an ETag MUST only use If, or is 
a client allowed to submit a state token with If AND submit an ETag with 
If-Match?

In text, the two options might look something like this:

    0.  When If is present, evaluate it:

        *  if true, continue to step 3

        *  if false, respond 412 (Precondition Failed)

    1.  When If is not present and If-Match is present,
        evaluate it:

    ...

OR

    0.  When If is present, evaluate it:

        *  if true, continue to step 1

        *  if false, respond 412 (Precondition Failed)

    1.  When If-Match is present, evaluate it:

    ...

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Dec 2012 12:03:09 +0100

> Happy Holidays to All!

I would recommend that you re-send to the HTTP mailing list. Are new 
conditional headers an extension point that needs to be described 
specifically? It seems that a specification that registers a new 
conditional header needs needs to define how it interacts with the 
others; and thus we probably should add this to the "considerations for 
new header fields" part...

Best regards, Julian

---

From: Ken Murchison <[email-masked]>
Date: Tue, 25 Dec 2012 11:57:03 -0500

> new header fields" part...

Hi Julian,

HTTPbis, part 4 already has text stating that extensions need to define 
how additional conditional headers are expected to play with others, 
which is why I brought my question to the WebDAV list.  I can certainly 
take it to the HTTPbis list of you still feel that is the best place.

   "Any extension to HTTP/1.1 that defines additional conditional request
    header fields ought to define its own expectations regarding the
    order for evaluating such fields in relation to those defined in this
    document and other conditionals that might be found in practice."