Running Wicket Behind A Front End Proxy

Many organisations choose to hide their web apps behind some kind of front-end proxy server. There are various ways to set this up. For example, you can set up mod_proxy in an Apache server host configuration like so:

ProxyPass /<contextPath> http://appserver.company.com:8080/<contextPath>
ProxyPassReverse /<contextPath> http://appserver.company.com:8080/<contextPath>

Where <contextPath> is replaced by the context path you've deployed your wicket application under.

The

ProxyPass

directive causes request URLs to be proxied to the specified host. The

ProxyPassReverse

directive causes 302 redirects from your app server to be rewritten to point to the front-end proxy instead, so they continue to work properly.

For more recent versions of Apache (2.2+) you need to add the following:

ProxyPassReverseCookiePath /<contextPath> /

Why this doesn't always work

Many people like to run their applications on CNAMEd virtual hosts for their different services (for example, Google™ run maps.google.com, images.google.com, etc.) This can cause problems, because many things that run on the servlet framework, Wicket included, construct URLs using absolute paths based on the context path that the app is deployed in.

In the mod_proxy example above, this works fine, because the path on the proxy is the same as the path on the app server. This also works fine if your app server only runs one application in the root context, because you'll have something that looks like this and everything will just work:

ProxyPass / http://appserver.company.com:8080/
ProxyPassReverse / http://appserver.company.com:8080/

However, where you run into trouble is if you have a set-up that looks like this:

<VirtualHost ordering.company.com>
  ProxyPass / http://appserver.company.com:8080/ordering/
  ProxyPassReverse / http://appserver.company.com:8080/ordering/
</VirtualHost>

<VirtualHost billing.company.com>
  ProxyPass / http://appserver.company.com:8080/billing/
  ProxyPassReverse / http://appserver.company.com:8080/billing/
</VirtualHost>

The problem with this is that although requests get proxied across just fine, by default Wicket will construct absolute paths to links, resources, etc. using the context path that the wicket servlet is deployed under (e.g. /billing). For example, if your wicket servlet is mapped to accept requests to "/wicket", this means anchor href links might look like this: "/billing/wicket?foo".

This works fine for development, but when you stick it behind your proxy, suddenly everything stops working, because you're trying to link to a non-existent /billing directory. So your page will show up fine, but any resource links won't work, and nothing will work if you click on it (you'll get 404s).

How to fix Wicket-generated links

Wicket 1.2 allows you to override the context path it uses to generate absolute paths for links, resources, etc. You can either do this in your web.xml file:

<servlet>
  <servlet-name>wicket</servlet-name>
  <servlet-class>wicket.protocol.http.WicketServlet</servlet-class>
  <init-param>
    <param-name>applicationClassName</param-name>
    <param-value>com.company.app.YourWebApplication</param-value>
  </init-param>
  <init-param>
    <param-name>contextpath</param-name>
    <param-value>/</param-value>
  </init-param>
</servlet>

...or in the init() method of your Application subclass like so:

getApplicationSettings().setContextPath("/");

Wicket 1.3 uses relative URLs, which neatly avoids this problem in the first place. Don't use setContextPath with Wicket 1.3, unless you're running a PortletApplication.