Re: Confusion in preconditions

Zhong Yu <> Wed, 01 February 2012 06:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 721F511E8095 for <>; Tue, 31 Jan 2012 22:13:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rxu3Pp0Z+3Rr for <>; Tue, 31 Jan 2012 22:13:00 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 87D1B11E808D for <>; Tue, 31 Jan 2012 22:13:00 -0800 (PST)
Received: from lists by with local (Exim 4.69) (envelope-from <>) id 1RsTQP-00046o-71 for; Wed, 01 Feb 2012 06:12:09 +0000
Received: from ([]) by with esmtp (Exim 4.69) (envelope-from <>) id 1RsTQD-00045x-TJ for; Wed, 01 Feb 2012 06:11:57 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1RsTQB-00039S-OR for; Wed, 01 Feb 2012 06:11:57 +0000
Received: by vbbfq11 with SMTP id fq11so928921vbb.2 for <>; Tue, 31 Jan 2012 22:11:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LoTQzoUV6LsFdI9sX4Duc9dILAbbhEIlh9wbhKgwVPU=; b=ayzks2PfhhGocCPqcyaUjUlgXBDokXSjqJEBF8efBne7++PzBThrq7kMFvm/JSobA9 0xN6NH44+WFuqO+g5jrweHW8u4LRwHj4mXFE3XQixl7qukdyq5EOHLUa95+0OhJxo0w+ OFDabpvxUhHpIf4IVTqZr2Cc8TkT1SOGQEWP8=
MIME-Version: 1.0
Received: by with SMTP id p14mr12232046vdd.20.1328076690241; Tue, 31 Jan 2012 22:11:30 -0800 (PST)
Received: by with HTTP; Tue, 31 Jan 2012 22:11:30 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Wed, 01 Feb 2012 00:11:30 -0600
Message-ID: <>
From: Zhong Yu <>
To: Sebastien Lambla <>
Cc: "" <>
Content-Type: text/plain; charset="ISO-8859-1"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-2.7
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1RsTQB-00039S-OR 81ecfd8fbef4b13bd756aba30ac49817
Subject: Re: Confusion in preconditions
Archived-At: <>
X-Mailing-List: <> archive/latest/12296
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>
Resent-Message-Id: <>
Resent-Date: Wed, 01 Feb 2012 06:12:09 +0000

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

    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

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.

Why does the spec instead "beat around the bush", going very
roundabout ways, only setting some constraints on some scenarios? Are
readers supposed to solve the riddles to learn the underlying model?

Maybe it's because many implementations existed before the spec, and
the spec had to be careful not to brand them as invalid. The spec was
content to merely record generally accepted practice in certain
scenarios, and to forbid generally unexpected/unaccepted behavior in
other scenarios. It did not know a simple model that approximates most
established implementations in all scenarios.

Given the boundary constraints listed in the spec, one may assume many
variants of implementations can be compliant. That may not be the
case. Maybe the constraints are contradictory. Maybe the constraints
are so tight that it allows only a few variants, and it'd be simpler
if the spec directly spells out the few variants instead of the
numerous constraints. It's hard to tell. We need someone who can read
through it without passing out.

Maybe we shouldn't worry too much. Implementations pretty much
anticipate only simple/common scenarios; that's ok because all
participants are similarly simple minded. If we request

    GET / HTTP/1.1
    If-Match: random-fake-etag

according to the spec the server MUST respond with 412 . But most
servers will (unconsciously) ignore the If-Match and return 200,
because no real world client would send such request in the first

Zhong Yu