Re: Host header issue

At 06:07 AM 9/10/99 -0700, you wrote:
>> From: Wilbur Streett <>
>> Resent-From:
>> Date: Fri, 10 Sep 1999 08:58:00 -0400
>> To: John Stracke <>
>> Cc:
>> Subject: Re: Host header issue
>> -----
>> At 01:57 PM 9/9/99 -0400, you wrote:
>> >> People?  I thought that this was technology?
>> >
>> >So how do you build technology? At eCal, we get people to do it.  :-)
>> >
>> >Seriously, though.  Engineering is more than coming up with the best
>> >technology; it's also coming up with something that can be built by real
>> people
>> >with real, human failings.  Protocols that are too complex for the
people who
>> >need to implement them will lose out to simpler protocols, if only because
>> the
>> >implementations of the complex protocols will be buggy and late.
>> And designing protocols in order to work around implementation failures
>> means that the unnecessary complexity is added to the protocol, which then
>> leads to more implementation issues, and then more complexity is added in
>> the protocol to resolve implementation issues, ...  and it spirals out of
>> control.
>> The reality is that elegance of design, (read, KISS), makes for a
>> technology that can be implemented, supported, and useful.  HTTP wasn't
>> designed by Commitee, and was simple enough that everyone could implement
>> it.  Hence, even with it's design flaws, it became popular.
>> The reality of technology acceptance curves being what they are, I don't
>> see much more progress on HTTP with the sort of design process and
>> decisions that occured with the Host Header.
>The Host header is a band-aid to a badly botched design (the lack of
>host information in the basic request is the botch): it is NOT a fix
>to botched implementations.  And we had to fix it without breaking
>existing deployed software.
>The consequences of this particular botch in HTTP/1.0 design have SERIOUS 
>operational problems, only really visible at scale (and not particularly 
>to those who worked on HTTP/1.1, but those people who deploy HTTP in volume 
>on the Internet).

So you admit that it was an operational implementation problem that caused
this design "fix".  Somehow I think that this operational problem could
have been resolved without adding a requirement of "Host Header" in
conjunction with the already defined Host information.  Breaking down a
request to map to a pool of servers isn't something that should have
affected the entire design of HTTP.

>Somehow, one requirement laid on the HTTP working group from outside
>to make sure this botch would reliably be fixed does not seem
>excessive to me.  It is, to my memory, about the only externally
>imposed requirement placed on the working group.  I don't remember
>much else externally required of us.  The complexity comes from
>having to retrofit a fix to a broken design.

So the design change was imposed by corporate interests that thought that
the proper fix was to break the existing design concepts for their own

>So please go review the history of this, before making opinionated
>pronoucement on the people wo worked on fixing this problem.

My statements were not an "opinionated pronouncement" on the people who
worked on fixing the problem.  I don't know the group of people you seek to
defend.  The protocol specification was not the appropriate place to solve
the server farm issues, particularly when it forces new issues into
everyone else's work.  Just because someone wants to run a server farm
doesn't mean that the basic protocol was "flawed".  The routing of HTTP
requests to multiple servers is not something that should have forced a
design paridign shift in the basic "peer to peer" design intrinsic to HTTP.

Expressing the design realities of "design by committee" is not an
opinionated pronouncement.  Perhaps if you have less political motivations,
and more basic design motivations, you'd see that I'm only expressing a
simple truth.  One that is certainly not limited to any particular group.


        Putting A Human Face On Technology ;-)

Received on Saturday, 11 September 1999 07:17:02 UTC