tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <>
Subject Re: svn commit: r757470 - in /tomcat/tc6.0.x/trunk: ./ java/org/apache/coyote/ajp/ java/org/apache/jk/common/ webapps/docs/
Date Tue, 24 Mar 2009 08:52:15 GMT
Rainer Jung wrote:
> On 23.03.2009 19:31, Mladen Turk wrote:
>> I read the "remote_addr" as a string that can recreate
>> the FULL remote address on the container side.
> We need to change JK and TC in a way, that old versions of each work 
> together compatibly with new version.


> Changing the forwarded data to include IP and port, would break this 
> requirement and change the behaviour of all existing Tomcat versions.

Well, it's the same with AJP_REMOTE_PORT. Any previous Tomcat
will pass that as a env var to client apps, while the one that
treat that as private will not.

> Maybe I miss something, but I think the workaround chosen in the commit 
> is safer.

It's the same thing. To be sure the admin on the mod_jk side must
be aware of the capabilities on the Tomcat connector side, and
decide weather to forward the remote port or not.

With AJP_REMOTE_PORT you will have an extra env var.
Using composite, getRemoteAddr() will return
on old Tomcat connector. The later will probably cause more
trouble then an extra env var.

Anyhow, if we stick with env vars (and it seems we would)
we should adopt some ruling. Eg. any env var starting with
AJP_ should be removed by the Ajp connector. This would
allow us future additions without having again extra vars
floating around if we add something new.

Next, the exiting code in tc6.0.x behaves weired.
On first request getRemotePort returns 0, and on following
requests it returns -1.


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

View raw message