tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [OT?] Virtual hosting - does the port need to match the URL port?
Date Wed, 18 May 2011 13:53:40 GMT
sebb wrote:
> If "stimpy" resolves to "localhost", what is wrong with that?
To be precise, "localhost" would resolve to whatever the local hosts file says it does
(usually, and "stimpy" would resolve to whatever either the local hosts file,
or the DNS system, says it does.  (Although the DNS system would never resolve "stimpy" to, so it would have to be the local hosts file.)

I was oversimplifying. What I meant was that no standard browser would ever do that.

But as you mention below...

> However, it was a misleading example, I should have written:
> http://123.456.123.456:8080/
> Host: stimpy:8080

Right.  As far as I can tell from the RFC (and what I know of Apache httpd and Tomcat),
that may actually work (except that the IP address above is not possible, but let's say
that's a typo) (actually, Firefox tries to resolve that, as if it was a hostname, and
fails with a "Server not found / Firefox can't find the server at 123.456.123.456"
message). ;-)

So let's say that your crafted (and non-HTTP compliant) client would really
a) connect to the IP:port ""
b) send a request like this :
GET / HTTP/1.1
Host: stimpy:8080

Then, if the webserver supports virtual hosts, and has a virtual host named "stimpy", it
would pass this request "GET /" to that virtual host.
And as far as I can tell, the port part of the Host: header would be ignored in terms of
selecting the virtual host.

(But if we refer to Konstantin's earlier post, Tomcat would nevertheless pick up that
port, and pass it to the webapp/context (as a request attribute ?).
So in fact this raises the question of what Tomcat would do if the request looked like this
GET / HTTP/1.1
Host: stimpy:9999

Would Tomcat pick up this fake port number and pass it to the context anyway, although it
has nothing to do with the actual port onto which Tomcat listened for that request ?

>> And then, in the request itself that is sends onto that connection, it will
>> /repeat/ that same hostname in the Host: header.
> By default, yes, that's what browsers (and HTTP stacks) do.
> But some stacks allow the Host header to be overridden, e.g. to select
> a virtual host which is not in DNS.
Maybe, but then as far as I can tell, by doing that you have created a HTTP client which
is no longer compliant with the HTTP RFC.
(The point being not that the Host: hostname "is not in the DNS", but that the content of
the Host: header differs from the original "authority" content of the URL).

> If one did not know about virtual hosts, one could ask the same
> question about the hostname part.

Yes, but if you are developing something for HTTP, you are supposed to know and abide by
the relevant RFCs.
Ignorance is not an excuse here.

>>> Does it ever make sense for the "Host" port to be different from the
>>> URL port? For example:
>>> Host: stimpy:9090
>> As far as I know, no.  And there is also no standard browser which would do
>> such a thing.
>>> As far as I can tell, Tomcat validates the format of the Host header,
>>> but otherwise ignores the port?
>>> Is that correct?
>> Kind of. It will probably ignore the port, because it is irrelevant.
>>> Does anyone know of other servers that make use of the Host port setting?
>> As far as I know, none.
> Ok, that's what I was asking.
But don't forget what Konstantin said about it.  Tomcat does not totally ignore it.

I guess the whole point of this all is : the Internet works, amazingly well, because the
rules of what you can exchange on it and how, are public, documented, (generally) precise,
and accepted by all who develop things for the Internet.  And also because it is generally
not in the interest of anyone to look for the loopholes in the rules and try to exploit
them (since you then get a product that does not work well with the others).
But people, including the well-meaning gurus who write the RFCs, occasionally make
mistakes or forget things.  So in case of doubt, you are always advised to try to figure
out the spirit of the RFC, and apply what you think is the most restrictive interpretation

(at least in what you are sending out).
I would not advise for instance to start writing client software which relies on the fact
that webservers /can/ often ignore the port in the Host: header, to start using it to pass
some information "on the sly" to some web application.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message