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

Re: About that Host: header....

From: Koen Holtman <koen@win.tue.nl>
Date: Wed, 20 Mar 1996 14:05:22 +0100 (MET)
Message-Id: <199603201305.OAA15183@wsooti06.win.tue.nl>
To: John C Klensin <klensin@mail1.reston.mci.net>
Cc: koen@win.tue.nl, 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
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/40
John C Klensin:
>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
>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.

We cannot *guarantee* accurate implementations of anything.

>For example, let's assume that we "require" that "host" be present in all
>cases as a way out.

This is what I propose.

>  That certainly simplifies the protocol a bit, because
>client implementations don't have to make choices about when to send it.

Yes, and a simple protocol has the highest change of being implemented
accurately.  Plus, major browsers already do this.

I do not have to prove to you that leaving the request line format as
it is and requiring Host in 1.1 guarantees an accurate implementation.
I can't prove that anyway.  I believe this option gives the best
changes of accurate implementation, though.

I would like to see some arguments from your side on why the
"long-term operability/ survivability of HTTP on the network" depends
on 2, which is requiring the full URI in the 1.1 request line.
Especially because 2 will break the short-term operability.

In my opinion, introducing mass breakage by requiring the full URI in
the 1.1 request line will _not_ make implementations more accurately
follow the 1.1 protocol.  Quite the contrary.  

>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",

Yes, this is the sticking point.

> then I suggest the problem is
>important enough to justify a full version number.

I don't think it is, but we can have this discussion after may 1.

>    john

Received on Wednesday, 20 March 1996 05:09:44 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:58 UTC