Re: About that Host: header....

Balint Nagy Endre <> said:
> In theory Roy is right, in practice the situation is somewhat easier:
> I added the following two lines to my CERN servers config file:
> Map	http://gatekeeper.bne.private*	*
> Map*	*
> and now the old 1.0 server accepts full URLs.
> I guess that the NCSA server can be tricked similarly.

Maybe -- I know that Apache/1.1b with the proxy additions is capable of
that, yes.  However, this is not relevant to what I was objecting to.
It is relatively easy to create a new HTTP/1.0 server which accepts
full URIs; in fact, I have been encouraging that for ages.  We can and
should require that capability for HTTP/1.1 servers.

The protocol question is what does the client send when it is requesting
a resource on an origin server or gateway (not a proxy).  The HTTP/1.0
protocol requires that the client only send the absolute URL path.
That cannot change and remain compatible with HTTP/1.0.

We then have two options:

  1) Send the Host header field in HTTP/1.x requests and remain in HTTP/1.x
  2) Send the full URI in HTTP/2.0 requests

There is no value in sending both Host and the full URI.  Both options
equally solve the problem of vanity hostname using up IP numbers.
HTTP/2.0 requires message conversion anyway, so Host can be dropped at
that time without impact to the protocol.

Option (1) can be implemented now by any client and has no impact
on deployment.

Option (2) cannot be implemented by any client until the IETF has completed
work on HTTP/2.0.  Even then, a first request on an unfamiliar server will
have to be done in HTTP/1.x in order to avoid a high entry-barrier to

Option (1) has already been deployed in current practice.

Option (2) won't be deployable for at least six months, and more likely
a year from now.

Now, please explain to me why option (2) is a better technical solution
to the problems we are facing today.

 ...Roy T. Fielding
    Department of Information & Computer Science    (
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056

Received on Sunday, 24 March 1996 19:37:50 UTC