Re: About that Host: header....

I've been a bit reluctant to comment on this discussion to the list, since I'm
serving as editor.  But in any case, here is my technical view.  And
the view is based on previous scars and overall technical design experience,
rather than the particular issue at hand. 

Several points to note:

1) the write up I made for Host: that sparked this discussion
requires servers to report an error if host: is not recieved AND the 
client claims to be 1.1.  It also requires servers to handle full URL's.
This currently feels to be the rough consensus of the group about how
to proceed.

I believe this error reporting will likely eliminate the problem
in a timely fashion, which satisfies the very valid needs of operational
servers and address use on the internet, even if the solution isn't
graceful.

We may be able to remove this lint in HTTP 1.2,
if 1.1 really becomes ubiquitous.  But then again, we may not, if 1.0 servers
don't die a timely death.

None the less, I believe we should understand the consequences of this
decision, and the possible outcome.

2) I agree with John Klensin on this one: protocols have a lifetime,
and the more lint they accumulate, the sooner they die, and in this
case, we are adding lint to the basic (most frequently used) request
in the protocol, which we may or may not be able to remove.

HTTP has already accumulated much lint in its evolution.

My experience with X's evolution drives this home to me personally; we started
with a protocol, which while a binary protocol, shared much of the same
fundamental problems that HTTP does (inability to understand the length 
of requests/responses without parsing the messages in detail, slow
to parse, various funny leftovers such as graphics derived from an obsolete 
graphics device (the HTTP analogy is the use of MIME for messages), etc.
(X Versions 1-10).

We came to the point, as X succeeded much more quickly than
we ever anticipated, that we had to redesign the X 
protocol entirely; this redesign was X version 11.  This is what
people now refer to X.  While small potatoes compared to the Web, it
did spark a $10^9 industry.

In the X case, we BARELY got away with this redesign, and only because 
everyone bought into it.  The redesign (X11) was hurried (by probably 6 months), 
which has hurt in various subtle ways to this day.  It is clearly
a vast improvement over X10.  But various things in X11 
are broken, and require work-arounds or cause performance problems; 
I will not bore this list with a  description of them.  
I am happy it has worked as well as it has, over the 
last 8 years of deployment.  But John's concerns about longevity of protocols
is VERY real, and the experience of those who have designed protocols
over the years should not be disregarded lightly.

The Host decision, if made where the current rough consensus I feel is,
will accellarate the day when we must deploy a replacement protocol.
Now this isn't entirely bad.  I believe the historical baggage of
HTTP 1.X is high enough in other areas to eventually force such a transition,

We should understand that we are hastening the day when HTTP 1.X will
need repacement, and will have less time to design whatever HTTP-NG 
ends up being.  And I can tell you that being hurried in the design 
of such a protocol can result in serious problems, you get to live with
for many years.

So lets make this decision (which sounds to me like it has been made
already, unless this message sparks people to reconsider their positions)
and move on; I just want everyone to realize the possible consequences.
				- Jim Gettys

Received on Thursday, 21 March 1996 11:04:11 UTC