Host header (and Proxies)

Michael Shapiro writes:
 > It seems that requiring a Host header for http/1.1 will make the http
 > protocol unuseable for URI's that do not have host information (eg
 > URNs).

This raises several interesting issues, actually, mostly about
proxies, as discussed below.

 > For URN schemes there may not be host information as part of the URN.
 > This is true of the path URN scheme.  The client may use a proxy to resolve
 > the URN.  And this proxy may speak http/1.1. Requiring a Host header
 > would make it impossible to use the proxy.

One could still use a proxy (talking HTTP to the client) to resolve a
path URN (or any other URL) because the Host the client would give to
the proxy would be the host *of* the proxy.  This means that the
client must know that it is talking to a server that is behaving as
a proxy and not the ultimate server.  

However, now that I think about it some more (after talking with
Michael about it), the idea that proxies are distinguisable from other
servers is falling apart.  

Currently with HTTP, the differences between servers and proxies are
that clients send the full URL to proxies, and there are some headers
and status codes specific to proxies.  The full URL is needed because
the proxy might be proxying some completely different URL scheme.
Other headers and status codes are needed because it is sometimes
necessary for the client to talk to the proxy specifically.  (This
generalizes to a chain of proxies too.)

But any server might be considered a proxy for the data that it
retrieves (or interacts with) on behalf of the client.  For example, a
server could interface with (or gateway to) a Unix filesystem or a
database system, and it may be necessary to pass authentication
requests through to the data store.  On the other hand, a proxy might
be completely invisible to the client and server - if this is setup in
a secure manner, this could be useful, for firewalls and caches for
example.

There is nothing new we need to add to proxies to make them act just
like servers, but there is more we need to add to allow servers to act
like proxies.  In particular, servers need to be able to accept
the full URL on requests, just as proxies do.  But perhaps clients
should continue to only pass the full URL if they are knowingly using
the server as a proxy.  This is to let servers and clients continue
to work as they do - it would be bad to break them at this stage.

So what have we gained by following this path to server-proxy
unification and how does it relate to the Host header?  My
recommendation is that the Host header may be sent to both servers and
proxies, but the client should use the host of the service that it
*knows* it is talking to, whether that is a server or proxy.

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

Received on Monday, 2 October 1995 09:46:12 UTC