Re: Host header (and Proxies)

Daniel LaLiberte writes:
> 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.

Either the spec is not clear on it, or we're just getting sidetracked.
The Host: header is to be used with HTTP URLS only, not URNs.  There
is no issue wrt proxies, and there is no issue wrt being forward
compatible with URNs.

> 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.

But the entire URL is passed to the proxy, and there needs not be a
Host header, or if there is, it should be replaced by the proxy.  And
with proxies you don't really need the Host: header, because there
isn't similar needs to have multiple IP address proxies.

> 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.

Yes; when people talk about proxies, there are really two main kinds
of them, out of which only one I would call a Web proxy, for clarity
(that's a proxy on your f/w, getting stuff for your internal users).
The other kind is a "reverse proxy", where a proxy appears as a normal
server, but retrieves its content from other servers (which in this
case may be inside the f/w).

> 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 this is exactly the reason for the Host: header.  We couldn't just
switch to using the full URL which would have been the right thing to
do to begin with.  Instead, for the timebeing we use Host:, until the
next major revision of the protocol makes it possible to just always
use the full URL.

And for URNs, we'll be smarter as to never mangle the URN to begin
with.

Cheers,
--
Ari Luotonen				ari@netscape.com
Netscape Communications Corp.		http://home.netscape.com/people/ari/
501 East Middlefield Road
Mountain View, CA 94043, USA		Netscape Server Development Team

Received on Monday, 2 October 1995 13:02:18 UTC