W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Confusion in preconditions

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 01 Feb 2012 20:39:36 +1300
To: <ietf-http-wg@w3.org>
Message-ID: <3b442e89fa90dc06621b6a1a7fcb6916@treenet.co.nz>
On 01.02.2012 19:11, Zhong Yu wrote:
> On Tue, Jan 31, 2012 at 8:35 PM, Sebastien Lambla wrote:
>> I *think* the specification does define partially a behavior when 
>> multiple
>> conditional headers are present in the scenario leading to a 304, or 
>> am I
>> misunderstanding the definition?
>
> I would say the spec lists some constraints, that must/should be
> satisfied, even in "undefined" scenarios. You may say that's "partial
> definition".
>
>     The result of a request having both ... header fields
>     is undefined by this specification.
>
> These explicit "undefined" disclaimers sounds out-of-place, given the
> general vague nature of the spec. It seems to be a cop-out: "don't
> even ask me what if these headers co-exist; I don't want to talk 
> about
> it"
>
> One must wonder, the problem of conditionals appears to be very easy.
> We can have a simple model and a simple procedure, that succinctly 
> and
> precisely defines behaviors in any scenario.


I am pushing to have the conditionals interpreted as a AND condition 
between all present conditionals.

  if anything needs a special status response -> do that
  if any of the conditions is invalid => 412 status
  if ( (If-Match x) AND (If-None-Match y or z) AND (if-modified-since T) 
AND ... ) => 2xx status
  otherwise 304 status


This *seems* to cover all the use cases and provide a useful consistent 
interpretation for which of the "undefined" cases might be useful or 
senseless as well.

I'm still waiting for someone in this WG with more experience to 
produce a use-case where that rule-of-thumb actually breaks something.

AYJ
Received on Wednesday, 1 February 2012 07:40:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:54 GMT