Re: About that Host: header....

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
>>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.

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

Koen.