tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
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 09:32:33 GMT
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
> 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.

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.



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

View raw message