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 127.0.0.1), 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
127.0.0.1, 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 "123.123.123.123:8080"
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
