W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: About that Host: header....

From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
Date: Sun, 24 Mar 1996 22:56:02 -0800
To: Balint Nagy Endre <bne@bne.dial.eunet.hu>
Cc: http WG <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <9603242256.aa23207@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/71
> On the other hand: host headers are interpretable only by host-aware servers,
> while full URLs are visible in every server.

But that is exactly the problem -- think of the economics of the situation.

The only servers that care about the host header are those that serve
multiple hostnames on a single IP address.  This will not change.
Note, however, that there are NO currently deployed servers which do
the above, since the HTTP/1.0 protocol (sans Host) does not allow for
them to exist.  This means that such servers can be made host-aware
at no cost at the moment the owner installs them.

Full URLs require upgrading most existing servers before any client can
afford to send the full URL on a request to an origin server or gateway.
Host doesn't require any server to upgrade, which is why it can be used
with HTTP/1.0 clients.

Keep in mind that we are trying to solve a particular problem:
the IP address space being used up too quickly due to vanity hostnames.
That problem cannot be solved until a sufficient number of clients
(I'd say about 80%) have implemented the solution.  With Host, all
clients can implement it now -- hell, we could probably reach the 80%
number by the time we finish arguing about the solution!  In contrast,
sending the full URL requires that existing servers change FIRST, and
only then can the clients start implementing the solution.

I must emphasize that servers do not get upgraded with the same frequency
as clients.  Over 10% of existing practice are still using servers that had
well-known security holes discovered in them a year ago!  There is no
evidence to suggest that people can be compelled to upgrade their server
software any faster.

The question is not which solution is more elegant or which solution
would be better if there were no current practice.  The question is
which solution will better solve the problem.  I claim that sending
the full URL will not solve the problem because it cannot be deployed
in a timely fashion.  Furthermore, attempting to deploy a full URL
along with all our other improvements to the protocol will just delay
everything.  The full URL can and should be deployed when we make
all the other incompatible changes to the protocol -- in HTTP/2.0.

Enough on this topic -- I hope that I have covered all the questions
that the ADs wanted to see addressed.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
Received on Sunday, 24 March 1996 23:03:24 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:16 UTC