Additional comments on the Host: header....

I think the following comments are worth adding to Jim's summary (and that
of the minutes) of the "host:" header situation and especially to the
"disadvantages" of a couple of the options.

* Protocols can accumulate only a certain amount of crud  -- extensions,
patches, fixes -- to remedy errors in the original or for which there wasn't
an adequate anticipated framework before they become too clumsy for further
use, development, or accurate implementation and start relying on the
robustness principle alone to keep them working.   It is very much in our
interest to postpone as long as possible the date on which we _must_ invent
and deploy an HTTPng in order to just keep the Internet working.   We
accelerate that date by adding complex interactions to HTTP now and push it
off by trying to make extensions as clean and minimally complexity-adding as
possible.  "You must use this if the format of that isn't thus-and-so"
creates unneeded complexity and, given that there are other alternatives,
should be avoided on that basis alone.  

* The extra turnarounds of a "try, and, if that fails, try something else"
situation are unfortunate, but have to be considered against the backdrop of:

   -- Very short halflives of Web clients and servers: if we push something
like this out there, it is likely to be a problem for a fairly short period.
A kludge that is forever is, well, forever.

   -- The growth of the Web and the Internet are such, if a new protocol
model is deployed tomorrow, a year from now half the users will never have
encountered the old protocol.

   -- Since the "fix" --upgraded software-- is known, vendors who move to
the newer protocol will have a competitive advantage and those who don't
will be put to a proportionate disadvantage.  In today's market, that is
likely to further encourage rapid deployment.  On the other hand, anything
that makes it less painful for an implementation to stay in place than
convert will put early converters at a competitive disadvantage.

It may also be worth noting that the "extra turnaround per connection" Jim
notes is a worst case.  I'd assume that smart clients, designed to optimize
whenever possible, would cache negative responses for a while so that, if
there are several retrievals in a row from the same server (a common
situation), only the first of the series would incur the extra overhead of
dealing with an older server. 

I contend that we have to bite the bullet sooner or later and that, given
the present growth rate and software rotation rate, doing it quickly and
well, even at the price of some short-term transitional marginally worse
performance, is likely to be less painful than trying to work through a
gradual transition and will leave us in much better shape a year or eighteen
months from now.


Received on Monday, 18 March 1996 15:18:37 UTC