Re: Solution to the CGI message trap

From: Roy T. Fielding (fielding@kiwi.ics.uci.edu)
Date: Tue, Aug 11 1998


To: Jeffrey Mogul <mogul@pa.dec.com>
cc: ietf-http-ext@w3.org
Date: Tue, 11 Aug 1998 03:16:31 -0700
From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-ID:  <9808110316.aa27955@paris.ics.uci.edu>
Subject: Re: Solution to the CGI message trap 

>Actually, the Ack response seems to have been Henrik's idea, I just
>suggested adding nonces.  Anyway, in the context of CGI responses,
>we already have a strong expectation that these aren't usually
>cached in current environments, so making them slightly harder to
>cache probably won't affect things much.  (Especially if the
>alternative is to make certain things simply too unreliable to
>do at all.)

That's not quite what I meant.  The client doesn't know if it is a
CGI or not, so it would have to send a nonce every time it used a
mandatory extension, which means all mandatory extensions would not
be cachable responses.

>Perfection might not be one of the goals of HTTP, but I searched
>the HTTP/1.1 spec for the first use of the word "goal", and found
>
>    The goal of HTTP/1.1 is to support the wide diversity of
>    configurations already deployed while introducing protocol
>    constructs that meet the needs of those who build web applications
>    that require high reliability and, failing that, at least reliable
>    indications of failure.
>
>I.e., "reliable indications of failure" is indeed one of the goals
>that we seem to have agreed upon.  (I wonder who wrote that sentence?)

There is no expectation of high reliability when the environment includes
resources that do not follow the protocol.  What HTTP/1.1 does is allow
compliant applications to have highly reliable communication by providing
sufficient controls to allow such communication to take place.

In general, it is impossible in a distributed system to ensure that
the other party does what it says it will do (or did).  The best that
can be done is extract some promise from the other party that it will
try to follow some shared set of protocol, and to do that you either
need to mandate it in the protocol version (which each party sends as
a part of every message) or explicitly request a promise from the other
party.  Demanding it at the same time the action takes place just doesn't
work unless the right to make demands and a requirement to enforce demands
is in the protocol being used by both parties, and that can only be true
if both sides are obeying the protocol.

....Roy