- 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>
> 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 http://www.ics.uci.edu/~fielding/
Received on Sunday, 24 March 1996 23:03:24 UTC