Hi Rainer, chiming in late... SSL support on the connector between loadbalancer and Tomcat is something that is requested from time to time. Usually from over-conscious security types.
We are using mod_jk today, because of: 1) we always used it. It works 2) it supports stickiness 3) the "jkmanager" interface 4) recently we started using JK_STICKY_IGNORE together with "mod_rewrite" to remove some balancing artifacts caused by clients remembering the session cookie When being forced to move to another connector (e.g. mod_proxy_http+mod_proxy_balancer), I would be most upset if there were no alternative to "jkmanager". We use it a lot to manage the restart of worker Tomcats. But then, given the proposed schedule, I will likely be retired before our software is moving to Tomcat-9 :-) Thanks Martin On Wed, Jun 27, 2018 at 6:50 PM, Rainer Jung <rainer.j...@kippdata.de> wrote: > Hi there, > > BZ56402 is an AJP feature request and Remy postet > > "IMO, with each day that passes, this enhancement becomes more unrealistic > and > less useful. I think the decision must now be made to either start it > immediately (with a volunteer ) or pass on it and freeze AJP for good." > > and Chris postet: > > "It might be time to let AJP die." > > Maybe a dev list discussion about plans for AJP should happen. I heard > several people interested in getting TLS support for mod_jk. Whenever I was > thinking about it, I refrained from starting to work on it, because > > - good TLS support is a lot of work and I'm not sure how good mod_jk could > reuse mod_ssl like mod_proxy does. mod_jk uses common source code for IIS > and Apache httpd with only a thin wrapper for the individual web servers. > Therefore it is not easy to integrate the details of comunication, which > happens in the common source code part, with mod_ssl. > > - even if it would be done with lots of efforts, it would probably take > quite some time to become robust and I think there's not enough interest > and available work time to support that new and complex code for a longer > time. > > Since encryption would be most of the most useful features and IMHO we > won't get there, I suggest we discuss deprecation and EOL dates for AJP - > meaning mod_jk and AJP connectors. > > There's no need to rush, but there could be a clear statement, that no > feature improvements will be done and users should plan for moving to > mod_proxy_http (or other http/https) clients. > > I think it would be better to invest time in improving mod_proxy where it > still might lack. For instance adding custom headers to transport > communication info from the proxy to the backend like AJP does and which > could be noticed by our Tomcat http connectors and/or support for the PROXY > protocol. > > So what do people think about: > > 1) adding a statement to the mod_jk docs, that we don't plan any feature > enhancements and suggest users to migrate to mod_proxy_http and the TC HTTP > connectors (but what about IIS? I think there are reverse proxy modules > there as well?) > > 2) Adding a similar statement to the connector docs for AJP to TC 7-9. > > 3) Deprecating AJP in TC 9 and removing in TC 10 > > Regards, > > Rainer > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- ------------------------------------------------------ Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
