Re: Getting full URI to the server

> Why not pass the full URI in a header line?  No change to the request
> line necessary, and essentially upwards compatible.  Perhaps:
> 
>   Full-URI: http://foo.bar.org/index.html

This, or some variation upon it, has been discussed several times
on the mailing list.  The most common response is that it includes
too much extra information which would better appear in the Request-URI.
Rather than discussing that again, let's simplify it a bit:

   Host: foo.bar.org

since that is the only thing interesting which was left off the request.
[Before anyone mentions it: no, the port number is not interesting].

We should then ask ourselves why this is desirable and what it allows
us to achieve?  The only desirable aspect is that it allows a single
IP address and port to use the same default root address for multiple
hostnames.  For example, both

   http://www.ics.uci.edu/    and    http://liege.ics.uci.edu/

get resolved to

   http://128.195.1.5:80/

If those two hostnames were intended to represent separate organizations,
as in the case of a single server providing Internet-presence-for-hire
(i.e., vanity hostnames), then there may be a slight political/marketing
problem if the result was a page that required the user to select from
all of the various home pages.

Note that it has no other advantage, as the only non-distinguishable link
to that server is the root.  So, the next question is what would adding
a "host" header (or the equivalent) achieve?  Well, we already know that
existing clients do not support such a header, and it would take quite a
bit of time to get them to, so the server cannot rely on its existence
to provide the switching mechanism among the intended home pages.  Thus,
the best that it can do is provide a supplement -- if the header is present,
the choice is made automatically; otherwise, the user is presented with
a "choose one of the following" default page.

The next question is: are there any better ways of accomplishing what
is desired?  The answer is Yes and No.  Yes in that just putting the
full URI in the Request-Line achieves the same effect (plus many more
important effects) and would be consistent with the existing protocol
for communicating with proxies.  No, because doing so will not work with
1.0 servers and thus cannot be introduced before version 2.0.

The final question is: Does the additional functionality justify the cost
and effort of including the Host header in the 1.1 standard, with the
necessarily strong recommendation that it be included with all requests?

In my opinion, the answer to this last question is NO.  Allowing a server
to automatically choose the root URL from among the roots associated with
multiple vanity hostnames is simply not a sufficiently important piece of
functionality to justify its inclusion as part of the 1.x standard.

In order for such a feature to be added to the protocol, it will have to
justify itself externally to the standards process.  In other words, if
a sufficient number of WWW browsers and servers implement a header with the
above syntax and semantics, that header will be added to the specification.

When in doubt, bottom-up standardization is better than top-down.


......Roy Fielding   ICS Grad Student, University of California, Irvine  USA
                                     <fielding@ics.uci.edu>
                     <URL:http://www.ics.uci.edu/dir/grad/Software/fielding>

Received on Sunday, 12 February 1995 03:57:40 UTC