The Mystery of ProxyPassReverse
The mod_proxy_ajp module for Apache has many advantages over mod_jk for connecting a Tomcat server to an Apache front. For me, the crucial advantage was the ProxyPassReverseCookiePath directive, which allows me to map the session cookies of a Tomcat web application (other than the root application) into the root of a virtual host.
Unfortunately, many tutorials contain misleading advice, and recommend this pattern for the ProxyPassReverse, which will break if the web application issues a redirect:
1.ProxyPass /jspdir ajp://localhost:8009/jspdir2.ProxyPassReverse /jspdir ajp://localhost:8009/jspdir
The purpose of ProxyPassReverse is to rewrite the headers of HTTP redirect responses by a simple string substitution. Unfortunately, when the webapplication sends a redirect, it will send a redirect to a http: URL, not an ajp: URL. This will not match the argument of ProxyPassReverse, so the header will be passed through unchanged.
The working form looks like this, in a more complete example:
01.<VirtualHost *:80>02.ServerName www.example.com03....04.ProxyRequests Off05.<Proxy *>06.Order deny,allow07.Allow from all08.</Proxy>09.ProxyPass / ajp://localhost:8009/jspdir/10.ProxyPassReverse / http://www.example.com/jspdir/11.ProxyPassReverseCookiePath /jspdir /12....13.</VirtualHost>
Searching for mod_proxy_ajp produces 5 bad examples and only one good on the first page. I’ve found the broken form in pages from training companies, the Zimbra Wiki, and professionally published books.
How do so many people get away with this? AJAX applications such as Zimbra have no need to redirect, and simple JSP examples don’t redirect. In these cases the ProxyPassReverse line is simply cargo-cult configuration, copied from example to example and doing nothing at all.
No comments:
Post a Comment