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


From: Chuck Shotton <cshotton@oac.hsc.uth.tmc.edu>
Date: Mon, 13 Feb 1995 09:09:53 -0600
Message-Id: <ab6522b7050210047f75@[]>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:10 UTC