On 10.03.2009 17:02, André Warnier wrote:
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 3/6/2009 2:03 PM, Mark Thomas wrote:
Bing Zheng wrote:
The tomcat server (version 5.5.23) is behind a load balancer. If I
use request.getRemoteAddr(), it returns the load balancer's ip. If I
use request.getHeader("REMOTE_ADDR"), it returns the correct client IP
address. Is this a known bug? Thanks.
Nope, it is expected behaviour.
Is it? From the javadoc for javax.servlet.ServletRequest:
"Returns the Internet Protocol (IP) address of the client or last proxy
that sent the request. For HTTP servlets, same as the value of the CGI
variable REMOTE_ADDR."
I would think that if
!request.getRemoteAddr().equals(request.getHeader("REMOTE_ADDR")) then
something has gone wrong.
Perhaps a load-balancer doesn't count as a proxy under this definition?
I'd be nice if someone in the know would elaborate, because I would also
like to get to the bottom of this.
Logically, a webserver application could find out (through its webserver)
- the client IP address from the connection on which this request is
arriving. In case the request has been relayed by a proxy, load balancer
or whatever, this would however be the address of said intermediate
agent ('s host), who is the one making the real TCP connection to the
webserver.
OR
- the client IP address as indicated by a request HTTP header.
(And subsequently and possibly translated into a CGI environment
variable, if the server sets this up).
This one may, or may not, be the IP address of the original client.
Unless I am mistaken, I seem to remember that there exists for instance
a parameter in mod_jk, which allows to specify if the client IP address
forwarded by Apache to Tomcat should be the original client address (or
at least the IP address which Apache believes to be the client), or the
IP address of the front_end Apache server itself.
On the base of this, there seems to exist little doubt about what
request.getHeader("REMOTE_ADDR") does return (although there can still
be speculation about the content), but where does
request.getRemoteAddr() really get its data ?
Mark might correct me (especially w.r.t number 1 below):
1) There is no standard http header named REMOTE_ADDR. Not even within
Tomcat. So whatever you get out of this header depends completely on
whoever set it for you. It might not exist or contain garbage.
2) getRemoteAddr() gives you the address of the system, which opened the
connection. In case of an AJP connector, this is not true, because AJP
is meant to be used for reverse proxies. So here you get the address of
the system which opened the connection to the web server, forwarded via
AJP to Tomcat.
3) CGI variables like REMOTE_ADDR do not need to be directly related to
HTTP headers. In a sense the situation between a web server and a CGI
script is similar to a reverse proxy (those are also called Gateways,
remember what the G in CGI is for?).
4) Usually Reverse Proxies set a non-standard header X-Forwarded-For.
E.g. mod_proxy does. Be warned though, that cascading Reverse Proxies
will most likely add to the header, so it can contain multiple
addresses, usually comma-separated.
5) In the forthcoming mod_jk 1.2.28 you can even set the forwarded
client address to something else, e.g. in case you know there's a
reverse proxy additionally in front of your Apache (e.g. a separate SSL
eaccelerator) which sends you the client address via X-Forwarded-For,
you could instruct mod_jk to use the value of this header instead of the
address of the client as observed by Apache.
Some of this is exlained in one new documentation page of mod_jk, have a
look at the sneak preview:
http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/docs/jk-1.2.28-dev/generic_howto/proxy.html
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
