W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: About that Host: header....

From: John C Klensin <klensin@mail1.reston.mci.net>
Date: Tue, 19 Mar 1996 22:11:50 -0500
To: Koen Holtman <koen@win.tue.nl>
Cc: Ari Luotonen <luotonen@netscape.com>, jg@w3.org, Harald.T.Alvestrand@uninett.no, ari@netscape.com, paulle@microsoft.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, jeff@step.mcom.com
Message-Id: <2.2.16.19960320031150.0e2f9dd4@mail1.reston.mci.net>
At 17:50 96.03.19 +0100, Koen Holtman wrote:
>I too find that 2 is unacceptable.  Protocol easthetics is not nearly
>good enough a reason to break compatibility on such a fundamental
>level.

This is not a matter of aesthetics, it is a matter of long-term operability/
survivability of HTTP on the network.  If we could *guarantee* accurate
implementations of other strategies, I'd actually have fewer problems with them.

For example, let's assume that we "require" that "host" be present in all
cases as a way out.  That certainly simplifies the protocol a bit, because
client implementations don't have to make choices about when to send it.
But "require" doesn't mean anything -- there is no way to enforce the
requirement.  Even if we "require" that servers return an error message, it
just pushes the problem a bit further out.  We will find, I'm afraid
inevitably, that some idiot will decide to not bother sending "host" in the
interest of a few extra cycles of efficiency and that other idiots will make
the server error message a configurable option, also in the interest of
efficiency.    Extrapolation from the history of the Internet predicts to a
lot of such idiots.

And, behold, we will be exactly where we are today, but with one more
sometimes-implemented, effectively optional, bag on the side of the protocol. 

To fix it, we will have to change "GET" (and "POST", etc.).  Maybe we will
call what we get then HTTP 1.3, maybe 2.0, but that is another decision that
is in the hands of the WG (and the industry).  But, if the big sticking
point now is "1.1 has to be compatible with 1.0, and we can't put a change
like this in without calling it 2.0", then I suggest the problem is
important enough to justify a full version number.  The assumption that this
new collection of features and patches has to be "1.1" should, IMO, be
treated as just that -- a working assumption, not something inevitable if
good engineering requires otherwise.

    john
Received on Tuesday, 19 March 1996 19:31:28 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:48 EDT