FW: HTTP 1.1

Shane Kerr kerr at arin.net
Wed Jun 21 18:02:49 EDT 2000


Here's the issue:

When somebody wants their web page hosted, they really care about people
being able to get to it by name.  The usual stuff, http://www.arin.net or
whatever.  As we know from days of DNS training, what actually happens is
that it gets converted to an address, http://10.5.3.53 or something like
that.  The problem is that this means that each web site would require its
own IP address.  Given that there are lots and lots (millions) of web
sites, this would waste a significant amount of valuable IPv4 space.

The answer is to put multiple hosts on a single machine, using a single IP
address.  The problem is that if both www.arin.net and www.ripe.net use a
single IP address, clients will hit the same port (80) on the same
machine, and the server needs a way to know which URL the client really
meant to retrieve.

Enter HTTP 1.1, in which clients tell the server which URL in particular
they are looking for.  So when my browser goes to 10.5.3.53, it tells the
server that I'm actually looking for www.ripe.net, rather than, say,
www.arin.net or some other site hosted on the same box.  Then the server
can return the appropriate page and everything is groovy, IP space saved,
and the (virtual) world a better place for our kids.

The problem with *that* is that it requires that browsers be polite and
use the HTTP 1.1 protocol.  AFAIK, all browsers in the last couple of
years or so support HTTP 1.1 - we can check our own extensive server logs
to get some idea of what percentage of browsers are complaint.  

An additional problem is that (as noted in the document) many secure
servers (using SSL to provide HTTPS service) do not properly support using
names to return the appropriate pages.  *shrug*

Is it wrong to love this stuff?

I'm a little surprised at this document, because at our last member
meeting our members EXPLICITLY said they don't want HTTP 1.1 support to be
mandatory!  I haven't read the heavily edited minutes to see what they
say, however.  :(

Anyway, we (meaning "you all", since I'm leaving) can go the Apache and
iPlanet and whatever sites and give configuration information to our
members for web servers to turn on virtual hosting (we've actually done
this for Apache on zinc), but it will require someone tasked with making
sure it stays up to date and answering any e-mails on the topic.  Maybe we
want to set up a mailing list for this too (or just direct people to the
mailing lists that surely already exist for their web server software).

--
Shane Kerr <kerr at arin.net>
Senior Software Engineer
American Registry for Internet Numbers (ARIN)
+1 703-227-9877

On Wed, 21 Jun 2000, Debbie Herrmann wrote:

> I don't want to take on any additional tasks right now but I should
> understand what this is all about?
> 
> We can talk later.  It's quitin time!  Have a nice evening
> 
> Debbie Herrmann
> Engineering Manager
> American Registry for Internet Numbers
> 4506 Daly Drive, Suite 200
> Chantilly, VA 20151
> 703-227-9858
> debbieh at arin.net
> 
> 
> -----Original Message-----
> From: Barry Skeenes [mailto:bskeenes at arin.net]
> Sent: Wednesday, June 21, 2000 4:37 PM
> To: Debbie Herrmann
> Subject: HTTP 1.1
> 
> 
> Debbie,
> Here's the information I came up with re HTTP 1.1. It needs a review from
> someone who knows how to implement it. ISPs will need instructions on how to
> provide it to their downstream customers. Let's chat!
> Barry
> 
> ARIN GUIDELINES FOR IMPLEMENTATION OF HTTP 1.1
> 
> INTRODUCTION
> 
> ARIN subscription holders that provide virtual webhosting services, and
> organizations that request address space from ARIN are required to use HTTP
> 1.1. Many organizations have been utilizing a unique IP address for each
> domain they host. Since most ISPs provide webhosting service, this uses
> address space inefficiently and unnecessarily. Mandatory use of HTTP 1.1
> will significantly reduce the number of addresses needed for webhosting and
> help to conserve address space.
> 
> In utilizing HTTP 1.1, we move from an IP-based system of webhosting, to a
> name-based system of hosting. HTTP 1.1 enables multiple domains to be hosted
> by a single IP address. With IP-based virtual hosting, many hostnames can be
> hosted on the same server, but one IP address must be used for each
> hostname. In name-based virtual hosting, many hostnames hosted on the same
> server resolve to one IP address.
> 
> ISPs are also responsible for coordinating its use with their downstream
> customers. In order to save an extensive renumbering exercise, organizations
> that hold IP space received before July 1, 2000, will not be required to
> convert that space to HTTP 1.1. There are also a few exceptions to its
> mandatory use, which are described herein.
> 
> SSL, and its successor TLS, are used to provide channel-oriented security
> when HTTP is used for transmitting sensitive materials. HTTP can be used
> over TLS just as HTTP is used over TCP.
> HTTP 1.1 is layered over SSL (now succeeded by TLS), which distinguishes
> secure from insecure traffic by the use of a different server port.
> 
> According to RFC2068, HTTP 1.0 does not effectively address hierarchical
> proxies, caching, the need for persistent connections, and virtual hosts.
> HTTP 1.1 allows for multiple web sites to be supported from a single IP
> address. This helps to simplify large operational web servers where
> allocation of many IP addresses to a single host has proven to be
> problematic. HTTP 1.1 was designed to support previous HTTP versions,
> including 0.9, 1.0, and 1.1.
> 
> TECHNICAL CONSIDERATIONS
> 
> Some versions of SSL servers can support name-based virtual hosting while
> others cannot. In the event that your SSL server cannot support name-based
> virtual hosting,....
> Some SSL connections require a separate IP per website.
> 
> Currently, there is no software package to do a !reliable! accounting on a
> name-based
> basis. Organizations may need to set up a server as a sniffer and make
> changes to their network layout.
> 
> Bandwidth monitoring on name-based hosting is not supported by HTTP 1.1.
> 
> DNS is not fast enough for moving virtual hosts. One possible solution of
> redirecting to a new www2-host does not work in all cases.
> 
> Organizations should replace IP-based software with name-based hosting
> software for their downstream customers.
> 
> REFERENCES
> 
> http://www.ics.uci.edu/pub/ietf/http/draft-ietf-tls-https-03.txt, HTTP Over
> TLS
> http://www.ics.uci.edu/pub/ietf/http/draft-ietf-tls-http-upgrade-05.txt,
> Upgrading to TLS Within HTTP/1.1
> http://info.internet.isi.edu/in-notes/rfc/files/rfc2246.txt, The TLS
> Protocol Version 1.0
> http://www.ics.uci.edu/pub/ietf/http/rfc2616.txt, Hypertext Transfer
> Protocol -- HTTP/1.1
> http://www.ics.uci.edu/pub/ietf/http/rfc2617.txt, HTTP Authentication: Basic
> and Digest Access Authentication
> 



More information about the Policy mailing list