Re: Host header issue

> From: Wilbur Streett <WStreett@mail.Monmouth.com>
> Resent-From: http-wg@hplb.hpl.hp.com
> Date: Fri, 10 Sep 1999 08:58:00 -0400
> To: John Stracke <francis@ecal.com>
> Cc: http-wg@hplb.hpl.hp.com
> 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).

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

Received on Friday, 10 September 1999 06:12:18 UTC