httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: arrrrgh!
Date Fri, 02 Aug 1996 17:33:57 GMT
On Fri, 2 Aug 1996, Ben Laurie wrote:

> Hmmm ... not sure. How does the Host: header mesh with proxies? Like, do
> proxies pass it on unmodified, or generate their own?

I believe they pass it unmodified, if it exists, else they can make one.


> I don't see that we can change the handling unless we change the spec, too...
> on the other hand, come to think of it, it would be a very strange browser
> that connected on a port other than 80 and the expected the server to
> (virtually) connect it to port 80 because it had send a Host: saying so.

Yes, it would. But one could (and Apache does) interpret the spec that

> BTW, the more I think about these virtual port connections the less I like
> them. If a browser wants to connect on port 1234 instead of 80 it would surely
> do a connect directly to 1234 and not connect to 80 then send a Host: header?

One would hope so...

> So, it seems to me that the facility is only useful for crackers who wish to
> bypass firewall port filtering...

I dunno. The other way to interpret the spec, which is still correct, is
to still treat a non-port Host: header as port 80, but not allow port
switches. In other words, if the port sent doesn't match the port that
they've connected on, just ignore the Host: header. This is the same thing
we do, for example, if someone sends "Host: some.nonexistent.domain".

This would still give MISE the incorrect behavior for people who were
really using Host-based virtual hosts on non-80 ports, since they would
never match, and they would always get the default site for that port, but
that's their problem. At least it wouldn't screw up existing, IP-based,
multiport virtual hosts. This may be the best, to-spec, solution.

-- Alexei Kosut <>            The Apache HTTP Server

View raw message