Re: WebDAV If header field and HTTP conditional precedence

On 2012-12-26 16:35, Ken Murchison wrote:
> Happy Holidays to All!
>
> I'm trying to figure out where the If header field would fit in the
> precedence order outlined in:
> http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-21#section-5
>
> I'm assuming 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:
>
>     ...
>
>
> Thoughts?

This is an edge case, as "If" can do the test done by If-Match and 
If-None-Match as well (so there's never a need to combine them).

That being said, I suspect that many implementations implement "If" and 
the HTTP header fields in different layers, and weird things might 
happen in practice (maybe even depending on request methods).

 From a layering point of view, I'd recommend to test "If" first, and to 
proceed to step 1 if and only it it evaluates to true. We may want to 
raise an erratum against RFC 4918 so if the spec ever get's updated, 
this will be considered.

Best regards, Julian

Received on Friday, 4 January 2013 13:05:02 UTC