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

Re: Confusion in preconditions

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Wed, 1 Feb 2012 00:11:30 -0600
Message-ID: <CACuKZqE+Vw80aZNzFSOp9bSFoAQa+OYa4Bg91uNrsyBu0CjwDA@mail.gmail.com>
To: Sebastien Lambla <seb@serialseb.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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
Received on Wednesday, 1 February 2012 06:11:58 GMT

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