On 24.03.2009 09:52, Mladen Turk wrote:
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.
Yes, but changing the remote address by including the port is not spec
compliant, adding an extra ttribute, that is visible separately in old
versions is spec compliant (I assume there is nothing thet prevent
containers to add proprietary request attributes).
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.
Yes.
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.
Yes, I hesitated already now removing all AJP_* attributes from the TC
request object, because at the moment we only use it for exactly one
attribute, but it would probably be fine to prepare for further use by
hiding all AJP_* attributes.
Next, the exiting code in tc6.0.x behaves weired.
On first request getRemotePort returns 0, and on following
requests it returns -1.
Yes, I think it depends on whether it's the first request in a
connection, or a followup request. But since both values are wrong I
think there's not much value in "fixing" it to consistently return -1 or
0 when used with non port-aware JK.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
