- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Wed, 01 Feb 2012 20:39:36 +1300
- To: <ietf-http-wg@w3.org>
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 UTC