Fronting Tomcat with Apache HTTPD to Remove Ports and Context Paths
In this How-To guide, I show a combination of software and configuration to clean up URLs by removing the port numbers of the Java servlet engine (Tomcat) and the context path of the application. The goal is to create "cool URLs" that are are short (removing the unnecessary context path) and follow conventions (using the default port "80" rather than "8080"). OhioLINK also uses a custom access control module -- built for Apache HTTPD -- which makes the fronting of Apache HTTPD for Tomcat even more desirable.
Requirement
We're making use of the latest line of development for the Apache HTTPD series: version 2.2.x. The inclusion of mod_proxy_ajp -- replacing the custom "mod_jk" with a module that extends the httpd proxy engine -- in the latest major release of HTTPD makes our task much easier. This solution also uses HTTPD's mod_rewrite and an add-on module called mod_proxy_html. No additions or changes are needed to the stock Tomcat installation.
The Plan
There are two overall tasks that we're going to ask the HTTPD server to do. First, receive the incoming HTTP request and proxy it to the Tomcat servlet engine using the AJP protocol. Second, rewrite the URL paths of the headers and the X/HTML body from the Tomcat servlet engine to eliminate any instances of the context path. In a visual sense, what we are trying to is rewrite the path so it can be processed by Tomcat (the green box) then remove the extraneous parts of the path in the resulting headers and X/HTML (the red box):
Public Request URLs: | http://e.com | /remaining/path?and=params | ||
URLs sent to Tomcat: | http://e.com | :8080 | /context_path | /remaining/path?and=params |
URLs as output by Tomcat: | http://e.com | :8080 | /context_path | /next/page |
URLs as seen by browser: | http://e.com | /next/page |
The first half of this problem, modifying a request as they come into the Apache HTTPD server, will be handled by a mod_rewrite rule that rewrites the request to something Tomcat can understand then internally redirects it Tomcat via the AJP proxy. (Note that we are not using simply ProxyPass here because we want to send the request through the AJP interface to the Tomcat server, and RewriteRule allows us to do that with a [P]
flag at the end of the RewriteRule line.) The second uses a combination of ProxyPassReverse (a part of Apache-supplied mod_proxy extension that adjusts the URL in the Location, Content-Location and URI headers), ProxyPassReverseCookiePath (also a part of the Apache-supplied mod_proxy extension; it rewrites the path string in Set-Cookie headers), and ProxyHTMLURLMap (from mod_proxy_html, a third-party extension that rewrites URLs inside X/HTML documents).
Preparations
The 'mod_proxy_html' extension is likely new to your Apache HTTPD installation, so we need to download the source, compile it, and move it into the proper directory. Fortunately, this is rather straight forward:
1 2 |
|
Note that we are not using the mod_proxy_html author's 3.0 version here. In my set-up, the 3.0 version was causing Apache HTTPD to dump core on _every_request (whether proxied or not), and the prior release works just fine for our purposes. The apxs
line will compile, link, and copy the resulting library to the Apache modules directory for us.
The Configuration
This is the contents a 'tomcat-proxy.conf' file that is placed in the 'conf.d' directory of the Apache HTTPD configuration directory (most likely /etc/httpd/conf.d/tomcat-proxy.conf
, although your installation may vary).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
|
That's pretty much all there is to it. You should note that mod_proxy_html, like any HTML scraper, requires modestly well-formed X/HTML. If the markup is bad, the output from mod_proxy_html is likely to be unpredictable.