Subject: Re: Host header issue

From: Wilbur Streett <[email-masked]>
Date: Fri, 10 Sep 1999 08:58:00 -0400

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.

Wilbur

     --------------------------------------------
        Putting A Human Face On Technology ;-)
     --------------------------------------------
  Literally!  http://www.monmouth.com/~wstreett/FaceIT/

---

From: [email-masked] (Jim Gettys)
Date: Fri, 10 Sep 1999 06:07:44 -0700

> From: Wilbur Streett <[email-masked]>
> Resent-From: [email-masked]
> Date: Fri, 10 Sep 1999 08:58:00 -0400
> To: John Stracke <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Host header issue
> -----

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

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 please go review the history of this, before making opinionated
pronoucement on the people wo worked on fixing this problem.
				- Jim

---

From: Wilbur Streett <[email-masked]>
Date: Fri, 10 Sep 1999 09:38:32 -0400

>to those who worked on HTTP/1.1, but those people who deploy HTTP in volume 

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.

>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
reasons?

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

Wilbur