Re: About that Host: header....

I agree with Roy.

Roy T. Fielding said:

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

Yup, those sites that need it will have deployed the servers that
can handle the host header.  The rest won't care, and the Host header
will have considerably less impact on those other servers than the
full URL will.  The problem is getting the clients that send the Host
header adequately deployed.

> Note, however, that there are NO currently deployed servers which do
Not true, all the NCSA 1.5 servers handle the host header.

> 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 believe Netscape clients already support the host header (but you better
ask someone from Netscape) and the change is already in the pipeline for
the Mosaic clients.  So yes, I'd say the Host header is well on the way
to being supported already. 

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

Yes, Yes!  Additionally, I think that most server sites tend to upgrade
only when they get complaints.  So the previous solutions suggested where
the client silently corrects the URL based on the HTTP version number will
NOT encourage sites to upgrade, they will just increase traffic.

> 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    (
>     University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056

		Elizabeth(Beth) Frank
		NCSA Server Development Team

Received on Monday, 25 March 1996 09:14:55 UTC