Re: Confusion in preconditions

Zhong Yu <zhong.j.yu@gmail.com> Wed, 01 February 2012 06:13 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721F511E8095 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 31 Jan 2012 22:13:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxu3Pp0Z+3Rr for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 31 Jan 2012 22:13:00 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 87D1B11E808D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 31 Jan 2012 22:13:00 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1RsTQP-00046o-71 for ietf-http-wg-dist@listhub.w3.org; Wed, 01 Feb 2012 06:12:09 +0000
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <zhong.j.yu@gmail.com>) id 1RsTQD-00045x-TJ for ietf-http-wg@listhub.w3.org; Wed, 01 Feb 2012 06:11:57 +0000
Received: from mail-vw0-f43.google.com ([209.85.212.43]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <zhong.j.yu@gmail.com>) id 1RsTQB-00039S-OR for ietf-http-wg@w3.org; Wed, 01 Feb 2012 06:11:57 +0000
Received: by vbbfq11 with SMTP id fq11so928921vbb.2 for <ietf-http-wg@w3.org>; Tue, 31 Jan 2012 22:11:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.52.17.174 with SMTP id p14mr12232046vdd.20.1328076690241; Tue, 31 Jan 2012 22:11:30 -0800 (PST)
Received: by 10.220.192.137 with HTTP; Tue, 31 Jan 2012 22:11:30 -0800 (PST)
In-Reply-To: <3DDD0BE655869D4EA506652B3803AEF6C3519BA5@PRISM.caffeine-it.net>
References: <3DDD0BE655869D4EA506652B3803AEF6C3519BA5@PRISM.caffeine-it.net>
Date: Wed, 01 Feb 2012 00:11:30 -0600
Message-ID: <CACuKZqE+Vw80aZNzFSOp9bSFoAQa+OYa4Bg91uNrsyBu0CjwDA@mail.gmail.com>
From: Zhong Yu <zhong.j.yu@gmail.com>
To: Sebastien Lambla <seb@serialseb.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="ISO-8859-1"
Received-SPF: pass client-ip=209.85.212.43; envelope-from=zhong.j.yu@gmail.com; helo=mail-vw0-f43.google.com
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: maggie.w3.org 1RsTQB-00039S-OR 81ecfd8fbef4b13bd756aba30ac49817
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Confusion in preconditions
Archived-At: <http://www.w3.org/mid/CACuKZqE+Vw80aZNzFSOp9bSFoAQa+OYa4Bg91uNrsyBu0CjwDA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/12296
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1RsTQP-00046o-71@frink.w3.org>
Resent-Date: Wed, 01 Feb 2012 06:12:09 +0000

On Tue, Jan 31, 2012 at 8:35 PM, Sebastien Lambla <seb@serialseb.com> 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.

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
    Host: www.google.com
    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
place.

Zhong Yu