W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: Host: header and port number

From: Balint Nagy Endre <bne@bne.ind.eunet.hu>
Date: Wed, 24 Jan 1996 07:46:14 +0100 (MET)
To: Shel Kaphan <sjk@amazon.com>
Cc: http WG <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <609.bne@bne.ind.eunet.hu>
Shel Kaphan writes:
> Rob McCool writes:
>  > BearHeart / Bill Weinman wrote:
>  > >    Perhaps I'm missing something, but I can't seem to figure
>  > > out what a server would do with the port number.
>  > > 
>  > >    If a request comes in on, say port 80, and it says:
>  > > 
>  > >    www.foo.com:8000
>  > > 
>  > >    What does the server do with that?
>  > 
>  > Probably nothing. In outlandish theory it could provide a way for people
>  > to provide HTTP data from non-standard ports to people behind
>  > restrictive firewalls (the request came for port 80, but they're
>  > interested in the specialized stuff on port 8000 that their firewall
>  > won't let them get to).
>  > 
> 
> It's conceivable that a gateway would want to translate requests it
> receives on various ports to other ports on the other side (the
> inside) of a firewall.  If the original port were part of this header
> info, a gateway could even multiplex requests on many ports down to
> one, with the port number maintaining the information in a natural way
> as to which "virtual" server was being spoken to.  This is one way
> someone could organize  a single http server providing several virtual
> services.  For example you could set up externally visible services on ports
> 8000, 8001, 8002, ... and have them all translate down to port 80 (or
> whatever) on the inside of the firewall.
> 
> Maybe that is outlandish -- I'm not so sure.  It's not that much of a
> burning issue for me, though it feels more sensible to me to leave the
> port info in if it's there, rather than exclude it.
> 
> --Shel
Hmm. If a request contains a port number different from the port to which
it's sent, then the server is question should
1. refuse the request if it isn't acting as proxy
2. forward it in a usual way, if provides proxy service.
(at least CERN httpd can act as origin server and proxy on the same port)
consequently:
1.x proxies shall stuff in Host headers (sans port info)
and requests sent to origin servers or 1.0 proxies must contain
host header. (Other optimisation can be done by not sending host headers to
origin servers not depending on it -  having only one URL space. How to detect
this situation on proxy/client side is an another question, which we should
discuss soon, but that's a cache key issue)

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>
Received on Tuesday, 23 January 1996 22:58:16 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:43 EDT