You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Bing Zheng <bi...@gmail.com> on 2009/03/06 20:01:44 UTC
request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
Posted by Ilya Kazakevich <ka...@devexperts.com>.
Some proxies send client IP as "X-FORWARDER-FOR" header.
I am not sure, but probably tomcat uses it instead of REMOTE_ADDR in
getRemoteAddr()?
That is just a guess.
====================
Kazakevich Ilya,
MCP, SCJP
====================
-----Original Message-----
From: Christopher Schultz [mailto:chris@christopherschultz.net]
Sent: Tuesday, March 10, 2009 6:45 PM
To: Tomcat Users List
Subject: Re: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
-----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?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm2iuIACgkQ9CaO5/Lv0PBEPQCgkT3kiGT9/nUUbmw6B8eTI7Kn
CusAnjzmfCLle3z3ZUgtvN3buVhy0mf+
=B3fe
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
Posted by Rainer Jung <ra...@kippdata.de>.
On 10.03.2009 23:10, André Warnier wrote:
>
> Rainer Jung wrote:
> [...]
>> 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.
>>
> Rainer, how does that combine with the mod_jk "ForwardLocalAddress"
> directive ?
>
> And, by the way, which local address are we talking about ?
> (I mean,if the front-end Apache server has several IP adresses, which
> one would it pass on to Tomcat ?)
Ah, actually forgot about that one. We then forward a local_ip field of
httpd as the client address. From the code of httpd it seems, that it is
the address, to which the connection came in. I'll double check and add
that feature to the new jk documentation page about proxies.
Thanks for asking,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
Posted by André Warnier <aw...@ice-sa.com>.
Rainer Jung wrote:
[...]
> 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.
>
Rainer, how does that combine with the mod_jk "ForwardLocalAddress"
directive ?
And, by the way, which local address are we talking about ?
(I mean,if the front-end Apache server has several IP adresses, which
one would it pass on to Tomcat ?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
On 3/11/2009 4:51 PM, Christopher Schultz wrote:
> Rainer,
>
> On 3/10/2009 12:19 PM, Rainer Jung wrote:
>> 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.
>
> Sure there is. It's been there forever:
>
> http://hoohoo.ncsa.uiuc.edu/cgi/env.html
> http://www.ietf.org/rfc/rfc3875
Sorry about that; I was thinking CGI /environment variables/, not /HTTP
headers/.
Given the difference, I would say that these two calls are /rarely/
guaranteed to return the same value:
request.getRemoteAddr()
request.getHeader("REMOTE_ADDR")
...because, as Rainer points out, there is no standard REMOTE_ADDR header.
Sorry for polluting the list.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm4JRkACgkQ9CaO5/Lv0PAHBACgsiu23cahM3UAKxWdmIiJCO2Z
YakAmwdS49qsYc48Fgay+AhF/RtNKK15
=Ak46
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
Posted by Rainer Jung <ra...@kippdata.de>.
On 11.03.2009 23:52, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Rainer,
>
> On 3/11/2009 6:45 PM, Rainer Jung wrote:
>> On 11.03.2009 22:22, Christopher Schultz wrote:
>>> Your previous message seems to say that mod_jk will provide the IP
>>> address of the server running httpd as the REMOTE_ADDR when seen by
>>> Tomcat.
>> I can't read that out of my previous message. Could you please cite the
>> statement where I wrote that.
>
> Apologies. Re-reading your message it's clear you said that AJP would
> deliver the "address of the system which opened the connection to the
> web server".
>
> Thanks for clearing that (me) up.
No problem!
And any improvement suggestions for the docs page I advertised are welcome!
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rainer,
On 3/11/2009 6:45 PM, Rainer Jung wrote:
> On 11.03.2009 22:22, Christopher Schultz wrote:
>> Your previous message seems to say that mod_jk will provide the IP
>> address of the server running httpd as the REMOTE_ADDR when seen by
>> Tomcat.
>
> I can't read that out of my previous message. Could you please cite the
> statement where I wrote that.
Apologies. Re-reading your message it's clear you said that AJP would
deliver the "address of the system which opened the connection to the
web server".
Thanks for clearing that (me) up.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm4QJsACgkQ9CaO5/Lv0PA84gCgiGbkv59r5QaE2ByrnkPBm7Vt
M5QAoLuBKsAg0YFpdE1aASpiPnp5IPkd
=wTG1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
Posted by Rainer Jung <ra...@kippdata.de>.
On 11.03.2009 22:22, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Rainer,
>
> On 3/11/2009 5:06 PM, Rainer Jung wrote:
>> No, because [mod_jk] tries to act transparent by default, so it passes the
>> original client/server situation to Tomcat and Tomcat patches it's
>> client and server data inside the AJP connector in order to present the
>> webapp the situation like it was at the web server.
>
> So, the REMOTE_ADDR environment variable is passed-through as... what?
>
> If mod_jk tries to appear invisible, then the value of the REMOTE_ADDR
> environment variable should be that of the original client (or, at
> least, the original client as far as httpd is concerned).
See below.
> Your previous message seems to say that mod_jk will provide the IP
> address of the server running httpd as the REMOTE_ADDR when seen by Tomcat.
I can't read that out of my previous message. Could you please cite the
statement where I wrote that.
> So, which is it?
I was not talking about CGI environment variables. mod_jk will not pass
any environment variables, because they don't exist.
If you use the CGI servlet of Tomcat, then Tomcat will set an
environment variable REMOTE_ADDR to the value of request.getRemoteAddr().
And as I said getRemoteAddr() will be the address of the web server
client, unless you played with configuration.
Caution: there is yet another possible set of data, namely request
attributes. Those are neither headers nor CGI env vars. Just so that
there is still another reason for confusion.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rainer,
On 3/11/2009 5:06 PM, Rainer Jung wrote:
> No, because [mod_jk] tries to act transparent by default, so it passes the
> original client/server situation to Tomcat and Tomcat patches it's
> client and server data inside the AJP connector in order to present the
> webapp the situation like it was at the web server.
So, the REMOTE_ADDR environment variable is passed-through as... what?
If mod_jk tries to appear invisible, then the value of the REMOTE_ADDR
environment variable should be that of the original client (or, at
least, the original client as far as httpd is concerned).
Your previous message seems to say that mod_jk will provide the IP
address of the server running httpd as the REMOTE_ADDR when seen by Tomcat.
So, which is it?
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm4K4kACgkQ9CaO5/Lv0PCnjACcDRKlhhkFNd9uZedoUOeaOZKx
4q4AnAwkwnpP5MHEGwpLoQb62aN+PEGy
=FoLB
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
Posted by Rainer Jung <ra...@kippdata.de>.
On 11.03.2009 21:51, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>> 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.
>
> [snip]
>
>> 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.
>
> Does mod_jk set any of these headers?
>
> X-Forwarded-For
> X-Forwarded-Host
> X-Forwarded-Server
No, because it tries to act transparent by default, so it passes the
original client/server situation to Tomcat and Tomcat patches it's
client and server data inside the AJP connector in order to present the
webapp the situation like it was at the web server.
But you can use mod_headers to additionally set those headers, if you
like to, and mod_jk will forward them.
As described on the new shiny proxy documentation page
http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/docs/jk-1.2.28-dev/generic_howto/proxy.html
those headers in a mod_jk setting relate to:
X-Forwarded-For: getRemoteAddr()
X-Forwarded-Host: getServerName()
X-Forwarded-Server: getLocalName()
at least when there is only one reverse proxy involved, so no
concatenation of data in X-Forwarded-*.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rainer,
On 3/10/2009 12:19 PM, Rainer Jung wrote:
> 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.
Sure there is. It's been there forever:
http://hoohoo.ncsa.uiuc.edu/cgi/env.html
http://www.ietf.org/rfc/rfc3875
> 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.
[snip]
> 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.
Does mod_jk set any of these headers?
X-Forwarded-For
X-Forwarded-Host
X-Forwarded-Server
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm4JD0ACgkQ9CaO5/Lv0PAvCACgqKdhdh88VaP7LG297RFuOv/m
5hgAoImJMS41Ms0mA7+8gXuHaMujAv13
=FNum
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
Posted by Rainer Jung <ra...@kippdata.de>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
Posted by André Warnier <aw...@ice-sa.com>.
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 ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkm2iuIACgkQ9CaO5/Lv0PBEPQCgkT3kiGT9/nUUbmw6B8eTI7Kn
CusAnjzmfCLle3z3ZUgtvN3buVhy0mf+
=B3fe
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: request.getRemoteAddr() vs. request.getHeader("REMOTE_ADDR")
Posted by Mark Thomas <ma...@apache.org>.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org