FW: HTTP 1.1
Debbie Herrmann
debbieh at arin.net
Wed Jun 21 16:57:16 EDT 2000
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