Re: your mail
Dave Kristol (firstname.lastname@example.org)
Mon, 8 May 1995 11:26:22 +0500
email@example.com (Jacques Caron) said:
> Hey, this gets on my nerves. When will someone do something about it? It's so
> easy to add a f...ing "Host: " or "Full-URI: " header that would enable us
> to do that without such a hack. Multiple IPs per host _is_ a hack. It can
> only be done on a small number of OSes, and it is a real waste of IP
> addresses. I _thought_ we were running out of IP address space. Looks like
> you guys just want to use it still more quickly!
> I have to agree that the guy that came up with this was clever, as this
> works with the installed base, but such a small modification of the
> protocol would be _sooooo_ easy to implement in both clients and servers
> that I think that every single client and server existing would be upgraded
> in a matter of weeks, and that the installed base would in a few months be
> 80 to 90% converted.
> One would still need a "choose which home page you want" page for the case
> when the server does not know who was in fact selected, and that would work
> for everybody till he switches to a newer client.
> So, why, _why_, *why*, WHY? A single line! It's so easy!
> The worst is, it's been discussed a number of times, everytime everyone
> agrees and says, OK, that's a good idea, let's do it, and then nobody
> moves. What should I do? Send every web browser and server author a
> personal mail to ask him to do it?
Yes, it has been discussed, and it is a good idea. The problem is
deployment. Suppose you're running a server for companies X and Y.
The server gets a request via an old client program, and there's no
Host: or Full-URI: header. What should the server do?
Here are some possibilities, all bad:
1) Always return the page for company X [Y]. Obviously this surprises
the customers of company Y [X].
2) Return a page that says "Follow this link to company X and this link
to company Y." But company X may not like to be mentioned in the same
sentence as company Y.
3) Return an error.
I suppose one approach is to require conformance by browsers by date X.
Servers are not an issue -- a server only cares if it wants to offer a
service that depends on the new headers, and it might plan to do so,
say, at X plus six months. There's still the issue of how to deal with
old browsers. (Not everyone can or will get a fresh, shiny new browser
every couple of months.) A server could deny them access, but that's
not very friendly.