Over the years there have been a number of connectors developed to enable Apache httpd to communicate with Tomcat that have used a variety of protocols. When searching the web for information on how to do this, it isn't unusual to stumble across some really bad, out of date advice. So first of all the only options you should consider for this are:
All of the other other options have not been supported for a number of years so you should avoid mod_jk2, mod_jserv, mod_webapp and any other module that isn't discussed here. There three above all are currently supported and are all actively developed.
My experience with providing support to customers at $work is that these days a typical customer is no more likely to hit a bug in mod_proxy_ajp than they are in mod_jk or mod_proxy_http. (A few years ago mod_proxy_ajp wasn't as mature but these days I don't see any difference.)
That brings us to the crunch question: HTTP (mod_proxy_http) or AJP (mod_proxy_ajp or mod_jk)? And the answer? It depends! Both protocols have their strengths and weaknesses. Which one is right for you will depend on your circumstances. The factors that normally affect this choice are:
- Is one protocol / module already in use?
- Does the communication between httpd and Tomcat need to be encrypted?
- Does httpd terminal SSL but the SSL information needs to be passed to Tomcat?
If you are already using mod_jk, mod_proxy_http or mod_proxy_ajp and it meets all of your requirements then there is unlikely to be a good reason to change it. It would be better to stick to what you are currently using and to have consistency across your httpd instances.
If you need to encrypt the communication between httpd and Tomcat then this is significantly easier with mod_proxy_http as you can just switch from the http to the https protocol. mod_jk and mod_proxy_ajp use the AJP protocol which doesn't support encryption so you have to implement that separately via an SSH tunnel, IPSec or similar. This can add significant configuration complexity to the httpd-Tomcat communication channel.
Where httpd terminates the SSL, providing the SSL attributes are exposed (two simple directives) then mod_jk and mod_proxy_ajp automatically pass this information to Tomcat and Tomcat makes it available to web applications without any additional configuration required. To achieve the same result with mod_proxy_http requires httpd to be configured to add the SSL information as http headers and a Valve needs to be configured in Tomcat to extract this information and to make it available to web applications. Making SSL information available to Tomcat is therefore a little more complicated with mod_proxy_http.
mod_jk and mod_proxy_* also have very different configuration styles. The mod_proxy_* directives are consistent with other httpd directives whereas mod_jk uses an external property file. For system administrators familiar with httpd, the mod_jk approach can look a little odd.
- If you need to encrypt the httpd to Tomcat channel, use mod_proxy_http
- If you need to expose SSL information to your web application, use mod_jk or mod_proxy_ajp
- If you are already using one of these modules then changing is likely to cause more hassle than it saves
- Given a completely free choice, I'd use mod_proxy_http just because the configuration is more consistent with other httpd modules, it is marginally easier to debug with Wireshark and it can use your existing HTTP connectors in Tomcat.
See also a presentation I wrote (http://people.apache.org/~markt/presentations/2012-10-Apache-Tomcat-Reverse-proxies.pdf) and Rainer Jung's additional comments on that presentation (http://people.apache.org/~markt/presentations/2012-10-Apache-Tomcat-Reverse-proxies-notes-rjung.txt)