Deciding between mod_jk, mod_proxy_http and mod_proxy_ajp

posted by mthomas on June 16, 2010 07:06 AM

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:

• mod_jk
• mod_proxy_http
• mod_proxy_ajp

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:

• Is one 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 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.

In summary:

• 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
• 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.

Mark Thomas is a Senior Software Engineer for the SpringSource Division of VMware, Inc. (NYSE: VMW). Mark has been using and developing Tomcat for over six years. He first got involved in the development of Tomcat when he needed better control over the SSL configuration than was available at the time. After fixing that first bug, he started working his way through the remaining Tomcat bugs and is still going. Along the way Mark has become a Tomcat committer and PMC member, volunteered to be the Tomcat 4 & 7 release manager, created the Tomcat security pages, become a member of the ASF and joined the Apache Security Committee. He also helps maintain the ASF's Bugzilla instances. Mark has a MEng in Electronic and Electrical Engineering from the University of Birmingham, United Kingdom.