- From: Chuck Shotton <cshotton@oac.hsc.uth.tmc.edu>
- Date: Mon, 13 Feb 1995 09:09:53 -0600
- To: David - Morris <dwm@shell.portal.com>, http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
At 12:45 AM 2/13/95, David - Morris wrote: >1) Most UNIX boxes can have multiple IP addresses, some per adapter and > some by having multiple adapters. In my limited to the metal > TCP and UDP programming I always could get BOTH IP addresses for > the 'connection' so if the host were configured for multiple > addresses, a simple change to the publicly available server code > (CERN & NCSA at least) would support differentiation. Faulty assumption #1. Not all Web servers run on Unix. And as time goes on, Unix will definitely be a minority platform for Web services, just like it is for all other applications. Relying on Unix-specific abilities to accomodate a cross-platform need is inappropriate. >2) A credible WWW server can be brought up on LINUX for roughly $2K > in hardware costs. Then you have a truly unique hardware box and > no tricks, just a rack full of servers attached to a LAN and thus > the Internet. No funny software, etc. Some people don't have $2k to spare. Why should a slow, balky standards process refuse a specific feature request from thousands of users, just because a few individuals writing the standard perceive that $2k isn't too much to spend for a unique hardware platform? >3) It wouldn't be a difficult problem with source access as with > LINUX etc. to modify the network support to allow a trully large > number of IP addresses per host. Hello!?! Why are we wasting IP addresses for vanity WWW names? I wish people would stop trying to engineer some duct tape and bailing wire solution using multiple addresses and just do the right thing. Add the damn host name to the HTTP request as a standard field and stop this interminable e-mail and news discussion. Given the number of people who have requested this capability, adding it to the standard would give them a new target for their frustrations - client and server authors. Their repeated whinings would insure quick acceptance of this addition across all client and server apps, so we needn't worry about it being implemented in a timely fashion. The HTTP standards people have a great resource here if they'd just elect to use it. Give users a standard that does what they want and let the "marketplace" take care of the implementation details. It will. > Each could be locally bound to > a different HTTPD or the HTTPD code modified to interrogate the > destination IP address and select the proper home page from > there. Sure, and a large service provider could easily eat up an entire class C address on a single server using your scheme. In case you haven't read the news lately, address space is running out and this is a poor solution. >Of course as is often the case, I may have missed a compelling reason why a >capability is desireable but if not I have attempted to illustrate >easy solutions which don't require standards activity. What you missed were the compelling reasons for it to be a standards issue. Hacking around with an address-based solution is not robust, not cross-platform, not economical, and not a wise use of address space. ----------------------------------------------------------------------- Chuck Shotton cshotton@biap.com http://www.biap.com/ cshotton@oac.hsc.uth.tmc.edu "I am NOT here."
Received on Monday, 13 February 1995 07:10:25 UTC