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.
My experience with providing support to SpringSource customers is that a typical customer is more likely to hit a bug in mod_proxy_ajp than they are in mod_jk or mod_proxy_http. It isn't that mod_proxy_ajp is particularly buggy, I used it myself for 18 months on a production system without a single issue, but that it has a few more bugs than the other two modules. The situation is improving but at the time of writing I would rank mod_jk and mod_proxy_http above mod_proxy_ajp.
That brings us to the crunch question: mod_proxy_http or mod_jk? And the answer? It depends! Both modules have their strengths and weaknesses. Which one is right for you will depend on your circumstances. The factors that normally affect this choice are:
If you are already using mod_jk or mod_proxy_http 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 when you can just switch from the http to the https protocol. mod_jk uses 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 automatically passes 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_http also have very different configuration styles. The mod_proxy_http 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.