W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: multi-host virtual sites for HTTP 1.2

From: John Franks <john@math.nwu.edu>
Date: Wed, 10 Jul 1996 11:28:27 -0500 (CDT)
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.91.960710112748.6762D-100000@hopf.math.nwu.edu>
On Tue, 9 Jul 1996, Paul Leach wrote:

> With the Host: header in HTTP/1.1 it is possible to efficiently and
> easily make a single host act as many "virtual" Web sites.
> 
> What I'd like to see in HTTP/1.2 is the ability to easily and
> efficiently make multiple hosts act like a single virtual Web site, so
> that one can build huge web sites.
> 
> For example,
> 	http://www.megasoft.com/
> could be the root of the whole, HUGE, publically accessible corporate
> web of the MegaSoft Corp. The mapping of this corporate web onto
> physical Web Servers should be flixible and mutable over time -- as the
> site grows, more servers need to be added; and as the content changes,
> the load on various pieces will change too, necessitating rebalancing
> the content across the servers, even if more aren't needed.
> 
> It is _almost_ possible to do this in HTTP/1.1 today. The 302 (Moved
> Temporarily) response can be used to automatically redirect someone who
> did a GET on
> 	http://www.megasoft.com/very/long/resource/path/because/its/a/big/site.
> html
> to
> 	http://server42.megasoft.com/its/a/big/site.html

...

> 
> Comments?
> 
> 

I think that much of what you want can be achieved in HTTP/1.1 with
the Content-Base header and the use of relative URLs.  For example,
the root server might serve just one root document, but it would also
set the Content-Base to server42.megasoft.com/whatever.  This would
cause all requests for relative URLs from the root doc to go to
server42, which could have been chosen based on current load, client
location, etc.  For a multiple level hierarchy you could repeat this
with the addition of using the document requested to pick the
content-base.

E.g. if the root doc contains links to docs A, B, C then server46 must
be able to serve these documents.  When it serves doc B, it can set
the content-base to server46B which must contain everything linked to
in document B.

I think this can work fairly well with proxies.  It would be necessary
to make sure (as much as possible) that the same server is always chosen
for a given proxy.  E.g. the "46" of server46 might be a function of
the client (or proxy) IP address.

John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu
Received on Wednesday, 10 July 1996 09:34:42 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:05 EDT