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.
Sure.
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 1.2.3.4:56789
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.
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
