Two proposals for HTTP/2.0

Here are two modest suggestions for HTTP/2.0 with their rationale.

1. Add a header to the client request that indicates the hostname and
   port of the URL which the client is accessing.

Rationale:  One of the most requested features from commercial server
maintainers is the ability to run a single server on a single port
and have it respond with different top level pages depending on the
hostname in the URL.  Service providers would like to have multiple
aliases for a single host and have URLs like

http://company1.com/, http://company2.com/, http://company3.com/

all return appropriate (and different) pages even though all the
hostnames refer to the same IP address.  This is not currently possible
because there is no way for the server to know the hostname in the
URL by which it was accessed.


2. Require (or request) that clients support relative URL's in 
   redirects (status 301 and 302).

Rationale: This is important for small special purpose servers
(e.g. gateways).  Such a server is simpler to write, more robust, and
more portable if it doesn't need to know its hostname or port.  At present
there are two reasons a server needs to know its hostname and port.
First if it supports CGI it is required to supply this information
and second for sending 301 and 302 redirects.  Normally a small special
purpose server would not support CGI and wouldn't send redirects.
However, in order to use relative URL's, a server must deal with
requests like  

	GET /dir1/dir2   
which should be 
	GET /dir1/dir2/

i.e. with trailing '/'.  The accepted (and perhaps only) way of handling
this is with a redirect from the first to the second.  Since clients
must handle relative URL's anyway there is little cost in having them
handle them in redirects.  On the other hand the cost for special purpose
servers of needing to know both their hostname and port is significant.


John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Wednesday, 16 November 1994 07:29:09 UTC