To: Harald.T.Alvestrand@uninett.no
Cc: klensin@mail1.reston.mci.net, ari@netscape.com, paulle@microsoft.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, jg@w3.org
Subject: Re: About that Host: header.... 
In-Reply-To: Your message of "Sun, 17 Mar 96 18:01:09 +0100."
             <199603171701.SAA08004@dale.uninett.no> 
Date: Mon, 18 Mar 96 11:52:51 -0500
From: jg@w3.org


I own this problem on the issues list.  I will clarify the issues
list, as it and the minutes do not capture John Klensin's presentation
or the discussion that occurred at the IETF meeting.

We have four options, as I see it.

1) (LeaveAlone) leave things as in HTTP 1.0.  No host header, incomplete URL's in
the protocol.

	Advantages: No change at all
	Disadvantages: Still use one IP address/vanity name.

I believe this solution is unacceptable to all concerned who understand
the problem at all.  The current situation is operationally critical at 
large web sites, and addresses need to be conserved in the Internet 
until V6 transition actually happens.  I believe the IESG would (correctly) 
reject any 1.1 specification that does not address this issue in
a believable fashion.


2) (FullURL's) 
a) Require full URL's in HTTP requests.
b) Require 1.1 server to accept full URL from clients.

	Advantages: simplicity (if we ignore the transition problems)
		Protocol not crufted up and complicated forever.
		Simplicity is next to godliness.
	Disadvantages: Interoperability problems of 1.1 clients with
		many/most 1.0 servers during transition.  Solutions to 
		these problems involve one RTT, as a 1.1 client would have to 
		handle an error, and retry using 1.0 syntax. (i.e. protocol is 
		kept simple, at expense of network traffic during transition,
		and complexity in clients during transition).  Extra
		packets are exchanged during transition to 1.1 to handle
		this error condition.  Client implementations are
		more complex, and performance poorer during transition.
		Might discourage transition to 1.1 (gives incentive to
		clients to lie about their version).

This is clearly what the protocol should have been from the beginning.  Sigh...

3) (Host) Current 1.1 draft:
a) Add host header, with current (or improved wording) in the specification.
b) Require 1.1 server to accept full URL from 1.1 or later client.
Transition to requiring full URL in 1.2, after 1.0 servers have been
replaced.
	Advantages: no interoperability problems.  No extra RTT during
		transition, or extra packets on the wire during transition.
	Disadvantages: High potential for implementors to "get it wrong"
		and thereby defeat transition to multiple servers at single 
		IP address.
		Another piece of cruft and complexity is added to the
		protocol, to be supported forever more.

John Klensin's assertion, which I believe personally, is that the risk is too 
high of implementors not correctly implementing the specification even
if the speciification is tightened up.
Such buggy implementations would not be detected anywhere, and deployment
of such buggy applications would likely occur.
Unless the problem is easily detected (and obvious) to broken client 
implementations, it is likely that code will be deployed which is
broken.  All it takes is one major client or server implementation
to get it wrong to impede transition another version cycle.


4) (Host+Error) My alternate on 3, suggested at the IETF meeting:

a) Add host header, with improved wording in the specification.
b) Require 1.1 server to accept full URL from 1.1 or later client.
  (so far, same as option 3).
c) Require server to generate an error if a 1.1 client is detected, and no host
information present (or more strongly, at the expense of extra bytes on
the wire, no host header present). 
Transition to requiring full URL in 1.2, after 1.0 servers have been
replaced.

	Advantages/disadvantages: same as option 3, but without the
		disadvantage of buggy implementations going undetected.
		If we succeed in getting even only one major server vendor 
		to implement error reporting correctly, I believe this
		solution will succeed in forcing transition.
		This requirement can be written into RFP's easily.
		But 1.X protocol is still crufty forever, and this
		solution adds another piece of cruft, and a small bit
		of implementation effort on servers.

Once either 3 and 4 have been implemented, a transition to 2) could
occur in a later HTTP version (presumably 1.2).

Discussion:

I personally see only options 2 and 4 having a high likelyhood of the 
"correct outcome" allowing multiple sites to be served from the same server, 
within finite time of starting to transition to 1.1.  
I believe the W.G. needs to select either 2 or 4 to resolve this issue. 

There was a statement by Ari Luotonen at the IETF meeting that he believed that
solution 2) to be unacceptable to Netscape.  Ari, is this true now that
you've had time to think about it?  Paul, can you see what Microsoft's
opinion on this topic is?

What say you all?
				- Jim Gettys